Gran parte delle infinite discussioni sulla gestione dei pacchetti si esaurisce nelle sterili guerre di religione tra i diversi sistemi antagonisti1, ma le poche volte che si cerca di affrontare il discorso in maniera un po’ radicale viene fuori il dolorosissimo: “è perfetta così com’è“: negazione dell’intelletto umano e delle teorie evoluzionistiche tutte.
Per fortuna, anche dopo più di un decennio di utilizzo di “repository”, io non sono mai stato completamente assimilato e sono uno dei non molti veterani che riescono a porsi domande dalla prospettiva di un utente normale. Probabilmente perché tengo sempre presente che il funzionamento di Debian non è legato a leggi di natura e che invece dipende da scelte di design esposte alla fallacia umana e dunque perfettibili.
Come dicevo anche in “MacOSX visto da un pinguino curioso”2 e3, la gestione tramite repository è comodissima per il software di sistema, dove mi auguro che resti sempre4, ma mostra decisamente il fianco scoperto quando si tratta di applicazioni di terze parti. Appimage è – in ordine cronologico – l’ultima delle possibili soluzioni a questo problema.
Cos’è Appimage
Telegrafica: si tratta di un sistema per distribuire applicazioni self-contained, costituite da un singolo file immagine di un albero di directory contenente anche eventuali dipendenze non standard. Le applicazioni così distribuite non necessitano di una vera e propria installazione ma vengono eseguite da qualsiasi posizione, e soprattutto non richiedono l’installazione di librerie non standard.
Somiglia per molti versi al sistema utilizzato da anni su Mac OS, ma mentre le app di Mac OS sono semplici directory con estensione .app, le appimage, come anche altre soluzioni simili, evolvono l’idea di Application Bundle racchiundendola in una immagine eseguibile, per cui abbiamo realmente la corrispondenza 1 file = 1 app. Ho spesso trattato di Klik in passato, sostenendolo a spada tratta e beh, dietro ad Appimage c’è proprio Probono, del team di Klik :)
“Nuooo nuon puoi ammuazzuare APT!” (cit pop)
Invariabilmente quando si parla di progetti del genere c’è sempre un problema di comunicazione di fondo, dovuto al preconcetto che l’affermazione di Appimage (o simili) dovrebbe automaticamente implicare l’eliminazione di altri sistemi tradizionali, quali APT/DPKG YUM/RPM e via discorrendo. Non è così: i due sistemi possono coesistere, proprio come avviene (ad esempio) su Mac OS con gran pro per gli utenti.
I casi di utilizzo di Appimage e quelli di sistemi tradizionali “a repository” possono in qualche modo coincidere, a discrezione dell’utente, del distributore o dell’impacchettatore, ma sono in larga parte ben distinti:
- Da una parte c’è il software di sistema, comprendente il kernel, lo strato GNU/Oracle/vattelappesca, il server grafico e la shell grafica GNOME/KDE/vattelappesca con le applicazioni di base del desktop. Questo è il regno indiscusso dei sistemi di gestione tradizionale dei pacchetti.
- Dall’altra parte c’è il software di terze parti, quello che si vuole solo provare, quello che si vuole usare senza installare librerie su liberie, quello che a volte necessita di copie di librerie astruse o in versioni astruse e che non possiamo far coesistere con quelle di sistema. Questo è il naturale campo d’azione di sistemi come Appimage.
La prima soluzione è comodissima ed è destinata a lunga e prosperosa vita, ma non è perfetta: è quasi sempre impossibile o molto macchinoso installare più versioni di una stessa libreria, c’è sempre il rischio del temuto inferno delle dipendenze (dependency hell) e soprattutto – per la colpevole e scandalosa mancanza della benché minima cooperazione tra i distributori – è motivo del più ridicolo spreco di energie nell’intero panorama del software chiuso e aperto, per cui ad esempio esistono letteralmente migliaia di pacchetti in centinaia di repository per ogni versione di Firefox, tutti incompatibili tra loro e nessuno ufficiale, tranne un ridicolo tarball distribuito da mozilla che uso solo io e qualche altro coraggioso giusto per mettere alla prova le nuove versioni.
La seconda soluzione non è una panacea definitiva e non è perfetta anche essa, ma ha tanti lati positivi che si riassumono in uno: è comoda. Scarichi un’applicazione, la rendi eseguibile e la usi5. Si tratta di un sistema complementare insomma.
Avremo applicazioni di 250MB solo per un editor di testo?
No. Le librerie incluse nelle appimage sono solo quelle non-standard, che non trovate già installate nelle distribuzioni supportate (tutte le principali). Difficilmente tali librerie non-standard portano le applicazioni a prendere più di una decina di mega o due, e in casi abbastanza selezionati.
Nei miei test ho trovato valori del tutto rassicuranti, qualche esempio: Opera pesa 15 MB, Firefox 9 MB, Chromium 20 MB, Blender 25 MB, Handbrake 5,6 MB, Transmission 3,1 MB, Shotwell 1,4 MB e non mancano app sotto ad 1 MB.
“E come la mettiamo con la sicurezza?” (cit pop)
Non la mettiamo. Chiunque può eseguire già adesso script e applicazioni scaricate da internet così come chiunque già adesso è liberissimo di aggiungere repository che potrebbero installare di tutto. Finché Linux è agli attuali ridicoli livelli di diffusione non sarà mai un problema, ma se anche aumentasse la sua utenza vertiginosamente sarebbe uguale. Mac OS infatti utilizza questo stesso sistema e ha percentuali molto ma molto più alte di utilizzo e diffusione, e lo stesso non ci sono problemi reali di sicurezza.
Se proprio volessimo argomentare, ci potrebbero essere anzi alcuni fattori che aiutano la sicurezza. Il primo è che le applicazioni non devono essere installate e quindi non c’è bisogno di assumere privilegi di amministrazione, il secondo è che se mozilla potesse creare un pacchetto io tenderei a fidarmi più di quell’unico pacchetto ufficiale per tutte le versioni di tutte le distribuzioni piuttosto che a fidarmi di migliaia di pacchetti creati da differenti impacchettatori. Se non altro per potermi considerare cittadino di Firefox a tutti gli effetti, come gli utenti Windows e Mac OS che partecipano alle statistiche dei download, non subiscono la ridicola controversia sul brand ecc ecc.
Portable Linux Apps
Se volete provare questo sistema non dovete installare nulla. Le principali distribuzioni più recenti già hanno tutto quel che occorre per avviare una Appimage scaricabile dal sito http://www.portablelinuxapps.org/, che contiene una selezione di alcune app più richieste.
Nota 1, attualmente per poter visualizzare le icone delle applicazioni bisogna usare app-thumbnailer, che è ancora in fase di sviluppo ma potete preventivamente scaricare da qui. Una volta installato basta rimuovere la cache di ~/.thumbnails e riloggarsi.
Nota2, come fatto notare più volte da Treviño nei commenti (grazie!), Appimage non funziona ancora su sistemi a 64bit!
Io ne ho provate un paio e ho notato con estremo piacere che funzionano senza alcun rallentamento percepito e senza problemi. L’unica cosa da fare una volta scaricata l’app che vogliamo provare è impostarle il bit eseguibile e poi possono essere posizionate in qualsiasi directory e avviate con un doppio-click, proprio come in Mac OS.
Ma basta scimmiottare Mac OS!
Dico da sempre che copiare stupidamente Mac OS è sbagliato e avvilente, ma quando lo faccio mi riferisco agli stupidi e inutili scimmiottamenti estetici e disfunzionali che in molti sono tentati di provare.
Qui non si tratta di impostare uno stupido tema grafico che ricordi Aqua e nemmeno di organizzare il desktop con dock mezzo-funzionanti (anche se ormai ci difendiamo bene anche su quel campo). Si tratta di un piccolo grande cambiamento di fondo, che non si può apprezzare da stupide schermate e che rende la vita dell’utente normale enormemente più semplice.
Ad ogni modo, oltre a Mac OS il sistema è usato ed è stato ampiamente usato. Di recente è tornato ad essere di centrale importanza con l’utilizzo di qualcosa di simile anche in iOS (ex iPhoneOS) e Android. Invito dunque tutti i puristi ad abbassare le armi :)
Voto: 9 tappi su 10
Son un sostenitore di Klik da anni e non vi potevate aspettare altro da me, ovviamente. Di nuovo, non siamo di fronte alla soluzione definitiva, ma se guardate il tutto in prospettiva rappresenta di sicuro il superamento di una lunga serie di problemi legati alla distribuzione di software di terze parti.
Il tappo mancante alla perfezione 10/10 è diviso tra il mancato supporto nativo alle icone delle applicazioni, edit: il mancato supporto da parte di sistemi a 64 bit e la necessità di dover rendere eseguibili le applicazioni/appimage prima di poterle avviare, ma sono più problemi dei distributori che di Appimage stesso.
Note all'articolo
- RPM vs DEB per dirne una sempre di moda [↩]
- Ri-lettura ri-consigliata [↩]
- Davvero, leggetelo [↩]
- Magari un minimo di cooperazione tra i principali distributori concorrenti sarebbe benvenuta [↩]
- Spero che si possa trovare un modo per superare anche lo scoglio del renderla eseguibile, ma questo dipende da quanto i distributori sono disposti ad integrare e benedire Appimage [↩]
Bell’articolo, che condivido quasi al 100%
Più analiticamente: la questione della gestione dei pacchetti è abbastanza annosa.
La soluzione mac-style ha un grande vantaggio: è comoda.
Queste appimage non dimentichiamo che, da quanto ho capito, funzionano su tutte le distribuzione.. è una cosa fondamentale, imho.
Mi piace parecchio questo elemento… :)
Finalmente qualcosa di universale, oltretutto, a differenza delle portable apps per windows, non ci sono cartelle inutili :D
La questione sicurezza non è da sottovalutare, ma se le applicazione che necessitano privilegi amministrativi vengono installate tramite repository ufficiale e si usa questo metodo per le altre io non vedo alcun problema :)
il fatto è che non è chiaro quali siano le “librerie di sistema”: ad esempio un programma che usa le librerie QT le include o no? perche ad esempio su ubuntu non sono di sistema e su kubuntu si….
e se ho una libreria di sistema richiesta dall’app ma essendo di sistema non è dentro il pacchetto ma è di una versione “sbagliata”
felipe, abbiamo il miglior sistema di gestione del software al mondo, quello dei repository, in cui tutti i software sono compilati per quella specifica distribuzione e specifica versione
su questo versante apple ci fa una pipp*
si ma come sempre, sapendo bene che killerapp opensource non sono *quasi* mai meglio della controparte commerciale/close, mettere un sistema che faciliti l’impacchettamento per:
-applicazioni terze parti (adobe suite?, office M$ *brrr*, autocad, vari prog di render, videomontaggio ecc ecc)
-applicazioni ultimissima versione (firefox? ogni volta un smadonnamento x aggiornare, amule e molti altri)
-applicazioni che si vogliono provare-e-basta (per cercare un id3tag editor ne ho installati 8 *!* )
-sento un vocina lontana…..videogiochi-ochi-ochi-chi-hi….
forse renderebbe l’amato pinguino molto piu amichevole…..
ovvero: mettiti dalla parte di adobe(esempio), che gia ci grazia *cofcof* con il suo bel flash player, magari sarebbero anche interessati a proporre un porting linux, ma se devono sistemare l’interfaccia e impacchettare per le 7/8 distro piu comuni, ogni una col suo “dependencyhell”, piu ogni singola versione ha le sue rogne (gia ubuntu ce ne sono 2 all’anno) per non parlare delle rolling……il tutto per 1% del mercato (ma è vero poi?mah) in TOTALE tra tutte le distro….ovvio che il gioco non vale la candela x loro.tantissimo lavoro poco guadagno….
approvo Appimage al 99% – cambiamo il nome percarità – Klick mi piaceva molto
d’altronde se tutti vogliono tenersi il loro tipo di repository, questa *è* la soluzione ad ogni male, con poco sforzo la comunity potrebbe veramente trovare l’uovo di colombo….
caspita c’è in ballo una delle migliori/piu caotiche cose che la scimmia abbia inventato, non vedo perchè non potrebbe avere questa miglioria…..
io al contrario non sono d’accordo che sia una miglioria
anche apple con il sistema app store si sta avvicinando ai repository
tornare ai vecchi installer alla windwos è un passo indietro
non uno avanti
Concordo con te. Se non altro perché AppStore e Android Market sono *esattamente* repository, quindi dire che Apple su iPhone usa il concetto di applicazioni universali è un pochino inesatto a mio parere.
Scusate il doppio commento, questa cosa invece migliora il concetto di Portable Apps su Linux che di solito non esistono… quindi per qualche programma particolare può andare bene in modo che me lo posso portare su chiavetta, ma allora bisogna sistemare il discorso della home specifica per ogni programma, come detto nei commenti più giù.
mi da errore :(
“./Leafpad 0.8.17: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory”
Idee? (libfuse2 è installato, ubuntu 10.4)
Immagino tu sia su 64bit… Dev installare la libreria a 32bit:
cd /tmp
wget http://archive.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse2_2.8.1-1.1ubuntu2_i386.deb
dpkg --extract libfuse2_2.8.1-1.1ubuntu2_i386.deb libfuse
sudo chown root:root libfuse/lib/lib*
sudo mv libfuse/lib/lib* /lib32/
rm -r libfuse
Ora potrebbe funzionare… Può darsi che non funzioni comunque nel caso in cui ti manchino altre librerie a 32 bit da cui gli eseguibili dentro l’appImage dipendano.
Funziona tutto quello che ho provato :D grazie mille!!!
danno errore:
HandBrake
./HandBrake svn3332: error while loading shared libraries: libnotify.so.1: cannot open shared object file: No such file or directory
Chromium
chrome: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory
Xara invece non trova imagemagik…
penso abbiano un bel po di strada da fare:D
Cerca le librerie a 32bit e il tuo sistema e a 64bit, non mi sembra così difficile…
6 comandi e funzia anche a 64bit… ma sei un grande!
a me xara non funge!!! rendendolo eseguibile ovviamente.
maverick per la cronoca
“la necessità di dover rendere eseguibili le applicazioni/appimage prima di poterle avviare”
dover dare esplicitamente i diritti di esecuzione ad un eseguibile mi pare un vantaggio; è vero è un po’ palloso :Þ
@mosqu: usi una distro a 64bit? ho lo stesso problema su una Squeeze a 64bit
si 64 bit …
Si veda sopra: http://pollycoke.com/2010/07/23/appimage-figlio-di-appdir-della-tribu-di-rox-appbundle-e-klik-par/#comment-27186
Senza AppImage a 64bit si fa poco (finché Ubuntu non si mette a ridistribuire anche le librerie a 32bit)…
Ubuntu 10.04 e non funge nemmeno un’app… :(
Su Fedora 12 ne ho provate un paio senza problemi :D
avrei però un dubbio/domanda:
prendiamo ad esempio firefox, con le sue estensioni e le sue impostazioni. dove vengono salvate le estensioni? e le impostazioni del programma?
perchè se venissero salvate all’interno del pacchetto potrei semplicemente copia-incollare il pacchetto con tutte le mie bellissime estensioni installate su un altro sistema, senza dover reinstallare niente.. e stesso discorso per le impostazioni!
L’AppImage usa le impostazioni utente standard… Non ha una “sua home”… Magari sarebbe interessante poter passare un parametro all’appimage stessa per definire se utilizzare una propria cartella home oppure una specifica (diversa da quella standard).
Come ti avevo scritto anche su Twitter c’è il problema del supporto su architetture a 64-bit (per renderle veramente “universali”)… Le AppImage a 32-bit ovviamente funzionano, ma in genere richiedono l’installazione di molte librerie extra a 32bit (a partire da una libfuse.so.2) e per lo meno Ubuntu non ne fornisce così tante tramite repository (né l’appImage fa un analisi con ldd per mostrare le mancanze all’avvio)…
Allo stesso tempo, di AppImage a 64bit non se ne vedono molte…
Tra l’altro il processo di creazione delle AppImage è piuttosto “misterioso”… Cioè, di fatto viene creata prima un immagine ISO che viene poi resa “eseguibile” e montata con FUSE al momento del lancio, ma al di là del chiuso AppImageAssistant non ho trovato procedure diverse che spieghino meglio la cosa tecnicamente (e, nel mio caso, su un x86_64 non riesco neanche a generare l’eseguibile, mi viene generata solo la ISO!).
Ah, per mostrare le icone dei pacchetti in realtà puoi anche usare deb-thumbnailer che ha la doppia funzione di mostrare le icone delle AppImage, ma anche (come emblema) ai pacchetti deb (qualora vi siano). Non mi risulta che importi cancellare la cache, né riloggarsi… Basta lanciare un
nautilus -q;)Non ho provato Appimage, ma che differenza c’è coi ports di *BSD?
Sì, che i ports di BSD funzionano (commento ovviamente superficiale), ne ho provati due e uno è crashato subito (firefox 1.0), l’altro handbrake non parte.
Boh, aspetto novità, per ora sto bene come sto.
Mah nutro parecchi dubbi e perplessità. Prendete per esempio Chromium. Provo ad avviarlo da terminale ed ottengo questo: chrome: error while loading shared libraries: libicui18n.so.42: cannot open shared object file: No such file or directory
Che significa…semplicemente che dovrei fare un downgrade del pacchetto icu che sulla mia Arch box è alla versione .44 e non alla .42. Non ci siamo…il discorso si chiude subito laddove le librerie linkate dall’applicazione siano leggermente diverse da quelle su cui è stato costruito il pacchetto. Sul Mac ovviamente questo discorso è risolto in nuce ma sulle distro linux, dove ognuno fa quello che gli pare, non vedo la luce.
Sono per il resto d’accordo nei principi ma fra il dire ed il mettere in pratica un sistema come quello del Mac (o anche solo simile) dovremmo rivoluzionare molte cose….
NB: come ricordato da Treviño, Appimage non è supportato sui vostri sistemi a 64 bit!
peccato ):
“siamo sempre l’ultima ruota del carro”.
“Pdor, figlio di Kmer ..della tribù di Star, della terra desolata dello Kvnir, uno dei 7 saggi:
Pdvur, Ganer, Astagarinfasaha, Param, Fusus, Tarim… .Pdor coLui che è, che è stato, e che sempre sarà, ciucia chi e ciucia là.”
il mio sistema è allergico ai bundle purtroppo! :)
ho trovato un progetto simile, non so se l’ho già linkato in questa epoca:
http://sourceforge.net/projects/infodomestic/files/
Milioni di volte è apparso nella vecchia messagebox ;)
eh, l’alzheimer incombe (:
Il progetto è italiano,
era proprio Luca Cappelletti a postare ;)
Comunque sta cosa “non funziona a 64 bit” non mi va mica tanto giu’.
Non possiamo rimanere indietro sui 64 bit,
su Windows non esistono piu’ programmi non funzionanti a 64 bit.
Tra i principali vantaggi IMHO derivanti dalla diffusione di un sistema come questo c’è sicuramente il colmare una lacuna rispetto a windows, dove le portable apps sono una manna dal cielo (io addirittura quando posso su win7 non installo, vado di portabile e spero così di sporcare meno il sistema) e inoltre la speranza di limitare la perniciosa tendenza che abbiamo di aggiungere PPA e repository semiaffidabili a volte solo per provare l’ennesima cavolata.
Riguardo ai 64bit, io pur avendolicontinuo ad installare linux a 32bit, tanto i 4+ GB di RAM è comunque possibile sfruttarli (installando il kernel server), è un pacco, ma mi sembra che salvo esigenze specifiche si possa anche vivere così.
non serve il linux-server per i 4GB, ma è sufficiente linux-generic-pae e linux-headers-generic-pae
ciao
Giuseppe
??nutro dubbi, ma non ho prove nè tempo per cercarle, per confutare la tua asserzione :)
Pure io tutto sommato nutro dubbi (non avendo provato direttamente in quanto mi bastano i 3.2GB che ubuntu32bit vede), ma ci sono un sacco di guide, ad esempio:
http://www.cyberciti.biz/faq/ubuntu-linux-4gb-ram-limitation-solution/
fidati, con un kernel-pae sfrutti + di 4GB anche sui 32bit
>su Windows non esistono piu’ programmi non funzionanti a 64 bit
Dici? :)
in realtà windows a 64bit fa girare i programmi 32bit tramite WOW (windows on windows). In pratica c’è un windows a 32 bit dentro a windows stesso che fa girare gli applicativi a 32bit.
Soluzione imho dispendiosa però in effetti soddisfa le esigenze di tutti :)
su linux si potrebbe LOL (linux on linux). perchè no? è pure divertente!! LOL :D
Commento precdente: sorry, ho sbagliato a fare reply, non voleva essere una risposta diretta all’utebnte GNAM
Concordo, ma alla fine noi quante apps di terze parti usiamo ?
Le uniche apps che uso e che non sono nei repo sono apps non Open, es: Opera e Skype, tutto il resto è dentro i repo (Sui repo di Debian-sid ho trovato di tutto e di più).
Quindi alla fine Portable Linux Apps servirebbe solo a far girare app non free, o magari app di cuoi non si vuole installare repo extra.
La cosa sarebbe di grande vantaggio per i nuovi arrivati da OSX o da Windows ma per chi usa GNU/Linux (e sopratutto APT e Debian) da anni comprende subito che tale innovazione serva a poco.
Ovvio che se lo implementassero in distribuzione come Ubuntu ne sarei felice perché sicuramente ne aumenterebbe la diffusione :)
purtroppo la teoria dei repositoris parte dal presupposto che lì dentro ci sia tutto.
ci sono veramente tutti i software dell’universo?!!? a me risulta che nelle vecchie versioni di ubuntu i repository sono stati chiusi e quindi è “quasi” impossibile metter roba nuova (anche a livello sperimentale)
appunto “nelle vecchie versioni”
Ma in distro rolling non vi è sto problema (vedi debian-sid), e su Arch ci sta Aur che è super figo.
Poi a partire da Ubuntu 10.10 sarà presente un nuovo repository dove potranno essere inclusi nuovi software quindi sarà quasi-rolling relese.
Quindi si può arrivare alla conclusione che il sistema repository per molti versi è meglio del sistema PortableApps.
> Quindi alla fine Portable Linux Apps servirebbe solo a far girare app non free, o magari app di cuoi
> non si vuole installare repo extra.
Quoto, perché distribuire altro tipo di software creerebbe solo inutili conflitti e dipendenze mancanti con le librerie. Inutili perché puoi sempre richiedere che ti includano tale software nei repository :)
A dire il vero io un programma del genere lo vedrei meglio su winzozz, ad esempio per istallare MinGW e compagnia bella (i cui pacchetti al momento fanno tristemente pena.)
Mi hai quasi convinto! Però rimangono alcuni punti critici da risolvere, tra cui:
1) nomini più volte le “librerie standard”: stabilire quali siano e in quali versioni è cruciale. Apple risolve la questione semplicemente perché, su questo, non deve mettersi d’accordo con nessuno: una volta rilasciata una nuova versione del sistema operativo effettua solo i minimi aggiornamenti indispensabili a correggere i bug, e uno sviluppatore può dichiarare con sufficiente affidabilità: “Il mio programma richiede Leopard, oppure Snow Leopard” etc. Nella galassia Linux questo è, allo stato attuale, molto difficile. Ci dovrebbe essere un’opera di standardizzazione ampiamente supportata dalle maggiori distribuzioni, che scenda molto più nel dettaglio di quanto attualmente non faccia la LSB. A esempio: “la versione 2011 delle specifiche Linux prevede le librerie glibc versione x.x compilate dal compilatore gcc in versione y.y e con i seguenti switch di configurazione, nella versione a 32 bit e/o a 64 bit” etc. etc. Insomma, tra discussioni tecniche e politiche, una mole abnorme di energia sprecata (e chissà con quali risultati).
2) a proposito di comodità: è molto comodo, sulle distribuzioni Linux, avere l’aggiornamento automatico del parco applicazioni. Su Mac OS X, invece, ogni applicazione fa storia a sé: ci sono quelle che controllano da sole se c’è un aggiornamento disponibile, quelle che scaricano da sole la nuova versione, quelle che si autoaggiornano (alla maniera di Firefox) e quelle che non fanno nessuna di queste cose. Insomma, c’è un po’ di incongruenza. Francamente, da utente Macintosh, questa degli aggiornamenti è una delle poche cose che Apple ha da invidiare alle distribuzioni Linux. Come si possano gestire in modo efficiente gli aggiornamenti senza i repository centralizzati, però, non riesco a capirlo: la stessa Apple, per iOS, lo fa con l’AppStore che altro non è se non un repository stile Debian.
Insomma, il progetto è interessante, ma ci sono alcune condizioni oggettive che lo potranno limitare nella diffusione e nella capacità di avere successo. Se si arrivasse ad avere che, per esempio, di Firefox ci sarà il pacchetto deb per Ubuntu, quello rpm per Suse, quello rpm per RedHat etc. etc. ed in più anche quello AppImage, il progetto avrebbe fallito il suo scopo…
Secondo me il probelam non sarebbe tanto quello degli aggiornamenti (basterebbe integrare le appimage nel software center e avvisare quando viene caricata una nuova versione usando lo stesso sistema che c’è), quanto quello dell’integrazione con il resto del sistema.
Perfetto! Spesso mi capita di provare qualche programma come Firefox in tarball e ora non ho più bisogno di scompattamenti e menate varie! Eccellente!
A proposito,c’è un modo di crearle? Davvero Firefox 4 mi torna più utile così! Diamine,io mi sento pessimista qui… Dubito che lo useranno in molti. Ci spero,però :D
si e’ possibile crearle :) basta scaricare l’AppImageAssistant da http://www.portablelinuxapps.org/
io invece credo che questo sistema prendera’ piede molto velocemente.
in primis perche’ e’ possibile utilizzare applicazioni senza inserire la pass da admin
inoltre si hanno altri benefici
ad es. un webdeveloper potrebbe avere a disposizione piu’ versioni dello stesso browser
Inoltre come per installare un applicazione basta scaricarla e impostarla come eseguibile, per disinstallarla basta cestinarla :D quanto e’ funzionale!
Mi chiede di scegliere una cartella per l’applicazione ma nessuna va bene O_o
Com’è che funzionerebbe di preciso?
http://www.elementary-project.com/wiki/index.php?title=Creating_AppImages
dà una occhiata qua.. a me non riesce però
riuscito.. ci ho provato con minitunes.. innanzitutto devi partire da un deb.. in pratica oltre a fare quello che dice in “Making an AppDir from a Deb” devi cercare nel deb che hai scompattato anche il file eseguibile e metterlo in quella che chiama AppDir’s root.. inoltre bisogna ricordarsi di rendere eseguibile lo script che hai salvato in quella cartella.. poi con appimageassistant selezioni quella cartella lì e poi fa tutto lui..
Abbiamo i repository che sono una bomba, mi chiedo come una soluzione win/mac-like possa mai portare alcun beneficio (trascurando tutti i difetti by-design).
Di solito chi produce software si adegua al sistema utilizzato per quel preciso sistema operativo (si sono adeguati ad .exe e .dmg), creare un pacchetto deb/rpm o un repository è ormai alla portata di tutti.
E’ questione di volontà di portare app su linux, non più un problema di pacchettizzazione.
Secondo me è *anche* un problema di pacchettizzazione, perché la volontà scappa quando per rendere disponibile un programma per Linux bisogna farne 200 versioni; con questo non voglio dire che appimage e compagnia bella possano risolvere questi problemi, ma mi fermo perché la questione deb/rpm/vattelapesca è sempre la solita solfa…
Quando hai l’1% scarso del mercato e aspetti che gli altri “si adeguino” creando non solo diversi tipi di pacchetto ma anche diverse versioni a seconda delle librerie presenti nelle distro che magari cambiano ogni 6 mesi, sai che ti rispondono di solito?
“Ceeerto! Non aspettarci alzato, pero’! Chiamiamo noi, eh?” *sirena di una nave che scompare all’orizzonte*
sai che fanno?
inviano i sorgenti sul ppa di launchpad che te li compila per tutte le release possibili.
senza sirene e ballerine. :)
bah, tutte cazzate.
con un tgz e gcc si fa tutto.
Giusto! E perche’ usare una nave per andare in Sicilia, Felipe. Basta nuotare!! X-D
non hai capito.
intendo che si potrebbero fare i srcrpm e srcdeb, poi ogni distro li compila come si fa abitualmente in un suo pacchetto, per le sue versioni. LOL
LOL
già gli srcrpm e srcdeb mi sembrano troppi, l’obiettivo di questa roba è creare il .PLA come ci sono per windows i puntoexe
sarò io ad essere un pigro niubbo che non vuole usare il terminale, ma (per qualche strana ragione) scaricare e fare doppio click mi sembra più immediato.
Non credo che adobe porterà mai la sua suite su linux finché non ci sarà qualcosa di simile ad uno standard per gli eseguibili.
Se la nomenclatura dei pacchetti fosse uguale per tutte le distribuzioni…
Grande! Non sapevo fosse cosi’ semplice. Mi sembra che le potenziali siano enormi.
Quante volte non si puo’ installere dai repository la versione successiva di un applicazione che magari corregge un bug mostruoso senza stravolgersi mezzo sistema e cambiare kernel…
Speriamo che qualche distribuzione con i soldini appoggi il progetto. Mi sembra uno dei passi obbligatori per linux al fine di uscire dalla sua nicchia.
Il mio sogno e’ una compatibilita’ alla XP dove posso installare ogni programma che mi serve e chissenefrega se il sistema e’ di 9 anni fa…
“Quante volte non si puo’ installere dai repository la versione successiva di un applicazione che magari corregge un bug mostruoso senza stravolgersi mezzo sistema e cambiare kernel…”
un programma che non si riesce ad aggiornare senza modificare il kernel?
nessuno?
indovinato?
tar.gz -> tasto destro –> estrai qui -> doppio click sul eseguibile (vedi firefox/thunderbird)
mi sembra alla portata del avanti-avanti-avanti degli exe e dei pkg del mac
certo che si vuole fare un pacchetto per ogni distro linux stai fresco (anche se i ppa di launchpad ti aiutano molto) ma se è per questo non credo che trovi gli exe per win98 aggiornati.
Certo perche i pacchetti tar si installano senza mai problemi e senza compilare mai niente e non c’e’ mai neppure il problema che serve la lib_youdonthaveit 3.4 ma per installarla ti serve otherlib2.4 che dipende da hell_lib666 che come dipendenza a ghost_lib 5.4 che e’ stata vista per l’ultima volta volare sul polo nord da un’esploratore artico nel 1942 ^_^
esistono i tar che contengono già il compilato (non devi ne installare ne compilare)
vedi firefox..
su centos4 che usciva con firefox2 misi firefox3 scompattando solo il tar.
certo che ti può capitare il sorgente da compilare con la dipendenza impossibile ma parliamo di casi limite, i repository contengono ormai anche l’impossibile.
vero! infatti per xp ci sono stati solo i sp1, sp2 e sp3 che non hanno creato grandi srtavolgimenti nel sistema.
praticamente quasi tutto funziona (se non sbaglio solo google chorme vuole l’sp2 per qualche motivo che non so)
compatibilità alla xp! orrore! orrorissimo…! e avvenne l’avvento avventuroso dei virus su linux…
Diversità anche in una sola distro per:
Sistema stabile (uso lavorativo) : solo repo ufficiale escluse terze parti se possibile [Non voglio blu death a lavoro!]
Sistema multimediale (uso casalingo) : tutti i repo + backport ufficiali [come spinta a migliorare solo piattaforme open per libertà di scambio contenuti]
Sistema per smanettone (uso artificiale) : anche sto benedetto “Klick” ^^
Xp non si prende virus perche’ e’ compatibile, dai.
Si prende virus principalmente perche’ si installano programmi crakkati e si aprono allagati.virus ^_^
sopratutto perché c’è un sistema di cacca della gestione dei privilegi.
con appdir basta non dare la password di sistema ed i danni sono ridotti all’osso
Pingback:AppImage, il bene? Forse si, forse no. | Bl@ster's Home
A me non dispiace la soluzione di Google: installando il .deb si aggiunge automaticamente anche il ppa, in modo da fornire aggiornamenti in automatico. Certo, si pongono problemi di sicurezza.
Su BSD ci sono i ports che funzionano da secoli, su PC-BSD ci sono i .pbi
http://www.pbidir.com/
Perché mi preme sempre invio prima di finire il post… e non posso nemmeno cancellarlo, uff.
Dicevo, su BSD ci sono i ports e PC-BSD ha un sistema di installazione che funziona da dio.
Eppure l’utenza BSD è minore che linux. Perché non è quello il problema per la diffusione di massa di linux. Almeno non il solo.
Il problema è che non c’è un supporto adeguato da parte di grandi case etc.
Secondo me questa soluzione non cambia nulla, anzi crea ancora più casino.
Quali sono e quali no le librerie standard?
Esempio, voglio installare K3B su Ubuntu, quest’ultima non ha una libreria QT\KDE di sistema da poter condividere, quindi presumo che sia impacchettata nella mia applicazione, bene!
Ora voglio installare lo stesso K3B su Kubuntu, quest’ultima di “sistema” ha tutte le librerie necessarie per installare ed eseguire l’applicazione ma questa al suo interno è stata costruita con le stesse librerie, quindi installo dei doppioni, male!
Morale della favola? Devo pur sempre creare dei pacchetti per singola distribuzione, anzi ancor peggio non posso nemmeno generalizzare con Debian based, RedHat, etc… .
Questo è solo un esempio molto banale ma questa soluzione così come concepita non risolve un bel niente ma è solo un altro sistema insieme ad i tanti.
Sarebbe invece più logico estendere il concetto che attualmente alcuni distributori software come Google stanno adottando. In pratica quando installi Google Chrome automaticamente loro di attivano un loro repository così sarai sempre costantemente aggiornato e non snaturi il sistema di gestione dei pacchetti che adotta la distribuzione. Ecco, magari, con opportuni studi per evitare conflitti, in questi repo aggiungerei anche eventuali dipendenze che se assenti nel sistema base vanno ad essere direttamente prelevati da questo repository.
Poi per quanto riguarda il concetto di distinguere sistema “base” da applicazioni terze sono pienamente d’accordo. Renderei infatti i due indipendenti e non come ora strettamente legati alla release della distro.
E col sistema che ho descritto sopra sarebbe altrettanto facilmente fattibile (e se non sbaglio è molto simile al sistema che Ubuntu adotterà per FF ed altri software terzi).
Sorry per l’Italiano ma vado di fretta. :p
Si, il problema è la definizione di “librerie standard” :)
Hai ragione e mi fai pensare a quello United Linux di diversi anni fa che voleva standardizzare la piattaforma. Ovviamente non se ne fece niente e la scusa ufficiale fu il comportamento di SCO, ma di fatto c’erano troppi interessi da portare avanti, soprattutto da parte della neo subentrata Novell.
Oggi le distro fanno a gara ad includere le versioni di software più recenti possibili e questo non aiuta eventuali nuovi tentativi di standardizzazione.
Concordo sul problema della definizione della libreria di sistema. Queste ultime possono solo essere il minimo sottoinsieme presente su tutti i sistemi.
Il concetto di avere un .app è lo stesso di avere una cartella in /local, che esiste per tenere separato il sw intallato con apt & co. con quello installato a mano (ad esempio compilando).
Già da molti anni (forse sempre) chiunque installi MATLAB – software matematico closed source e parecchio costoso – distribuisce una versione per *nix. Tutto il necessario per l’esecuzione viene installato barbaramente in una cartella specificata, java incluso. Il risultato è che posso installare la stessa versione su Suse 9.2 e su Debian sid del 2010.
Secondo me state tralasciando un fatto molto importante. Più importante del fatto di avere “n-mila versioni dello stesso software, in n-mila repository, in n-mila distribuzioni incompatibili”. Ed è quella di poter “installare” Facilmente una applicazione su un computer NON connesso ad internet.
Mi ricordo quando un amico, vedendo k3b mi chiese, “me lo metti su una chiavetta? io non ho internet”. Sbiancai.
Quanto ti quoto.
“Ed è quella di poter “installare” Facilmente una applicazione su un computer NON connesso ad internet”
Io invece non ti quoto per niente. Questa cosa oggi è DEL TUTTO irrilevante.
Ma sarà del tutto irrilevante per te che hai la fibra ottica in casa!
Immagina di essere il proprietario di un pc fisso in un luogo non raggiunto da ADSL (ancora troppi persino in Italia), e di avere una flat mobile con un massimo di traffico.
Improvvisamente poterti far passare il software su chiavetta diventa una cosa fondamentale.
nella mia zona (veneto, provincia di Verona) l’ADSL è arrivata da un anno.. e posso assicurare che i pc non raggiunti da asdl sono ancora molti
secondo me è una cosa stupidamente sottovalutata.
Basterebbe così poco per darmi la possibilità di installare un programma che (esempio) gestisce le connessioni wireless su un portatile che non lo ha… non dovrei sprecare tempo per cercare un cavo ed un ingresso.
Certo, sono esigenze che si hanno poco spesso… ma quando capita sono due palle immense.
Ma a questo punto è più una questione di driver che altro.
Teoricamente ogni distribuzione ha il suo gestore wireless installato.
Così come tutti gli attuali OS.
E questa soluzione risolverebbe il problema?
Come faccio a sapere a priori quali libreria sono o non sono di sistema?
Bisognerebbe comunque creare versioni specifiche da distro a distro, aggiornarlo sempre alle nuove modifiche in termini di librerie della distro su cui andrà ad essere installata l’applicazione.
Secondo me bisognerebbe intraprendere e migliorare la strada intrapresa da alcuni che ho descritto nel mio intervento precedente, anche per un uso locale.
Alex hai ragione a lamentarti, ma devi pensare che questo è un problema tutto italiano. Gli altri questo problema non se lo pongono, e non vedo perché dovrebbero.
Che ci piaccia o no, siamo un caso unico.
Sinceramente non vedo come questo sistema possa esser considerato migliore dei repository, che garantiscono anche aggiornamenti continui ed automatici.
Che poi l’utente medio gioverebbe di file auto-installanti che abilitino i diversi repository di terze parti a prescindere dalla distribuzione, questo è un’altro discorso: anche se c’è da dire che i PPA di ubuntu si stanno sempre di più muovendo in questa direzione.
In ogni caso ottimo articolo, molto interessante :)
Benvenuto in MacOSX Felipe!!! ;)
ciao..Se vi interessano i ruoli di genere sui mass-media vi invito a leggere il mio blog :)
Unabbraccio!
Ci sono sempre piu’ applicazioni per il momento.
In piu’ ci sono un sacco di situazioni in cui all’utente non e’ permesso installare applicazioni sul sistema, utente che trae veramente tanto giovamento da questo tipo di soluzioni ;)
Pingback:Portable Linux Apps anche su Sabayon « Sabayon Mania