Appimage, figlio di Appdir, della tribù di ROX, AppBundle e Klik (par)

felipe, 23 luglio 2010 @ 11:37 in Recensioni, Troiate del giorno - 95 commenti »
Etichette: , ,

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:

  1. 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.
  2. 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.

Bit eseguibile Alcune AppImage Change Menubar Button Position Arora

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

9 tappi

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 alla pagina:

  1. RPM vs DEB per dirne una sempre di moda [↩]
  2. Ri-lettura ri-consigliata [↩]
  3. Davvero, leggetelo [↩]
  4. Magari un minimo di cooperazione tra i principali distributori concorrenti sarebbe benvenuta [↩]
  5. 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 [↩]