Ogni volta che mi appresto ad avviare un installer sono preso da un sentimento di rigetto: mentre conosco (più o meno) lo stato del mio sistema prima dell’installazione, non so mai cosa devo aspettarmi dopo.
Il fatto che mi turba di più però è l’eventuale disinstallazione di quel programma…
Degrado post-disinstallazione
Sarà che il determinismo è una mera utopia, ma detesto trovare in giro per il disco file che ufficialmente avrebbero dovuto essere rimossi durante la disinstallazione dei loro rispettivi programmi.
Se restringiamo il discorso a Windows, le miriadi di chiavi orfane nel Registry mi irritano non poco.
Guardando questo fatto dal lato-sviluppatore, individuo almeno tre possibili “cause”:
- chi sviluppa gli installer non sempre produce anche il software stesso, per cui può non essere (legittimamente) a conoscenza di tutto quello va cancellato: molti file (es: quelli di configurazione) vengono creati in fase di esecuzione e quindi non compaiono nelle liste di rimozione;
- chi sviluppa gli installer non ha molto tempo da dedicare a quel task, rivedendo e correggendo la procedura di installazione per ogni singola sottorevisione di un programma (magari fra una release e l’altra sono stati inseriti altri file);
- l’azienda opta per lasciare volontariamente dei “rimasugli” post-disinstallazione per garantirsi la possibilità di identificare un’installazione “anomala” (leggi: copie pirata). Questo atteggiamento dovrebbe apparentemente tutelare l’azienda da un “utente non-cliente” ma risulta inutilmente punitiva per i clienti onesti. (*)
Delle tre opzioni certamente le prime due sono le più comuni per ragioni che vanno dalla pigrizia alla disattenzione fino alla fretta di rilasciare qualcosa “entro ieri“.
La terza è invece pura maleducazione, se osservata dal punto di vista dell’utente finale. L’utente ha il diritto a riavere le cose al loro posto dopo aver disinstallato qualcosa.
In Windows…
Personalmente ho sempre apprezzato i programmi che non necessitano di installer, magari contenuti integralmente in una sola posizione (una semplice directory): si decomprime un file compresso ed il programma è bell’e pronto per l’uso.
Non sto dicendo “al rogo gli installer!“: la classica procedura “avanti, avanti, avanti” (tanto bistrattata dagli informatici per via del fatto che l’utente-medio tende rapidamente ad abituarcisi e a premere sistematicamente sempre e solo su quel pulsante) e la possibilità di rimuovere il programma da un’unica interfaccia-pannello, garantiscono un approccio semplificato al problema dell’installazione/disinstallazione.
Ma cosa c’è di più semplice di poter installare e rimuovere programmi semplicemente copiando o cancellando directory intere (come avviene per molti bundle di MacOSX)? Si cancella quella directory ed il programma è disinstallato. Spettacolo!
In ambiente Windows, questo tipo di “installazione tramite copia” esiste ed ha un nome preciso, XCOPY deployment, dal nome del comando da terminale usato appunto per copiare file e directory (XCOPY, appunto).
Sfortunatamente non è sempre impiegabile: molti programmi, ad esempio, necessitano di installare anche librerie particolari o usare versioni specifiche, senza doversi portare dietro ogni volta doppioni locali rispetto a quelli di sistema.
Uno dei problemi che si cerca di risolvere (mascherare?) proprio con gli installer è la gestione farraginosa delle librerie di sistema in Windows nota come situazione nota come “Dll Hell”.
L’introduzione del Registry e di quel modo di gestire le varie versioni delle librerie sono scelte implementative che per certi aspetti si sono ritorte contro Microsoft.
Non per nulla, per evitare i celeberrimi problemi con le librerie, in .Net è stato aggiunto un meccanismo più intelligente noto come Global Assembly Cache (GAC) il cui utilizzo diretto tuttavia non è esattamente alla portata di un utente-medio.
Un invito
Se possibile, gradirei però che dietro a questa comodità per l’utente finale non si nascondesse la pigrizia nella pulizia di un programmatore…
Ciau! ^^
(*): sono dell’idea che qualunque mezzo per contrastare la “pirateria” debba risultare il meno invasiva possibile per gli utenti onesti. Un utente onesto reso vittima da complicati meccanismi di DRM è un abominio!
In realta’ il problema degli installer/librerie c’e’ anche su piattarforme non Win/Mac (leggi Linux, BSD).
Come ben sai uso Linux da diversi anni ed ho provato distribuzioni di ogni sorta e varieta’ (RPM based, DEB based, Portage based, Ports based, miscugli vari) ed in un modo o nell’altro sono sempre riuscito a rompere il sistema di pacchettizazione/risoluzione delle dipendenze per delle necessita’ particolari (quel dato programma richiede la versione x.y della libreria libxyz che pero’ e’ incompatibile con il resto del sistema installato) tanto da incominciare a pensare che l’unica soluzione in molti casi sia la compilazione dei sorgenti.
Il problema non e’ tanto Windows e le DLL (anche se nel caso specifico il caos e’ _totale_) quanto il fatto che esistano librerie condivise: si risparmia spazio e si razionalizza il sistema ma applicazioni non “well-behaved”, o non aggiornate (vedi API incompatibili tra release successive di libreria) diventano un vero e proprio peso sul gobbone.
Tanti distributori di software per utente finale si sono quindi ingegnati a ridistribuire comunque le librerie necessarie anche su questi sistemi (ad esempio QtCreator contiene comunque le librerie di sviluppo… e non sono proprio pochi mega), sperando che qualcuno della comunita’ crei poi dei pacchetti che tengano conto della restante struttura della particolare distribuzione (e non sempre e’ possibile).
Comunque ricordo di aver letto tempo addietro (non ricordo piu’ nemmeno il nome, pero’) di un formato di pacchettizazione delle app. Linux in stile Mac (ovvero super cartellona con dentro tutto).
jp, concordo con la tua irritazione.
infatti sono molto legato al concetto di distribuzione linux e all’uso il piu’ limitato possibile di pacchetti esterni. non mi piace sporcare il sistema neanche compilando i sorgenti.
i sistemi che girano sulle nostre macchine sono sempre piu’ vasti e complessi, e’ assolutamente necessario mantenere rigorosamente la situazione sotto controllo, visto che li usiamo per lavorare e anche una semplice reinstallazione comporta un bel po’ di “contrattempi”.
nonostante tutto, l’entropia non diminuisce mai, al piu’ rimane costante. finche’ ognuno e’ libero di scegliere il suo compromesso, siamo tutti contenti
@cavok: sì, il problema è universale ma nel caso specifico certi SO brillano meno di altri (diciamo così).
C’è una cosa che davvero non sopporto in Windows, ossia che programmi “comuni” si permettano di aggiungere/rimuovere DLL dalla directory di sistema “canonica” (es: C:\WINDOWS\system32). Questo perchè è prassi collaudata che le librerie siano lì dentro.
In Linux almeno c’è un po’ più di scelta (es: /lib, /usr/lib sono le soluzioni “canoniche” minime, poi se ne possono aggiungere, incluse nella directory utente) ed i programmi utente possono condividere librerie senza toccare quelle di sistema.
La bontà di un sistema operativo/sistema di installazione, IMHO, sta proprio nel modo in cui reagiscono alla presenza di programmi installati senza passare da loro.
@max: il fatto che l’entropia, intesa come livello di caos nel sistema, aumenti non è in discussione. Però si può cercare di controllarla un poco, evitando dispersioni di energie superflue.
Detesto dover reinstallare un sistema operativo ogni tot mesi solo perchè rallentato orribilmente da rimasugli di programmi ufficialmente rimossi da eoni…
“Se sporchi, pulisci“: perchè la sporcizia post-disinstallazione se la deve smazzare sempre l’utente finale?
In fondo non è così difficile mettere tutte le dll dipendenti in un unico bundle, un eseguibile che raccoglie tutto, alla maniera di NeXTStep. Poi con i dischi che abbiamo adesso non dovrebbe essere un problema.
Un modo elegante per farlo con .Net è con la reflection e il trap delle chiamate di ricerca delle dll. Quando un pezzo di codice chiede una dll si preleva dalle risorse e la si fornisce. L’effetto è che tutto il programma con tutte le dll e tutte le risorse annesse stanno in un unico, grosso eseguibile.
Ecco un tool che lo permette, molto elegante nel codice e nell’uso, è uno strumento che uso sempre nel deploy:
http://madebits.com/netz/index.php
No, il problema non è farlo ma il fatto di portarsi dietro potenzialmente una valanga di duplicati non è nè elegante nè consigliabile. I giochetti con le librerie le si fanno facilmente mettendo le dll nella stessa directory degli esegubili o “aprendole” specificando dove cercarle (la reflection in .Net è il modo più comodo per aprire e accedere al contenuto: è un netto miglioram).
Molto interessante il programma che hai suggerito!
La famigerata condivisione di librerie in Windows/System32, tanti anni fa, era anche una buona idea, ma francamente oggi mi sembra un autogol di progettazione (vedi DLL hell, sporcizia e altri problemi).
Ho sempre pensato che, se si vogliono condividere componenti a livello di sistema, meglio registrarli come servizi e dare la possibilità al S.O. di farli ‘vedere’ alle singole applicazioni. Un sistema simile agli smart pointers (della serie ‘lo tengo finchè almeno una applicazione lo usa’), gestito interamente dal S.O., potrebbe infine decidere quando disinstallarli. Purtroppo lasciare questa responsabilità alle singole applicazioni diventa decisamente poco robusto, basta che ce ne sia uno progettata male e comincia l’inferno ..
Uhm… Che io sappia, l’intera infrastruttura di Microsoft, da COM in poi (quindi oggetti dentro dll), usa il refcounting ma il problema sta proprio in quello che dici: la gestione era in parte a carico del programmatore (leggi: implementare l’interfaccia IUnknown)…
Fortuna è nato .Net…
Ciao & grazie! ^^