Pensieri e parole su HCI, home computing, tecnologie desktop e sul Progetto Lobotomy

Visualizzazione post con etichetta packagemanagement. Mostra tutti i post
Visualizzazione post con etichetta packagemanagement. Mostra tutti i post

venerdì 14 gennaio 2011

Aggiornamento nell'Ombra

0 commenti
Manco il tempo di finire di scrivere il precedente post sui potenziali vantaggi di un meccanismo di aggiornamento interno alle applicazioni, in grado di pescare autonomamente informazioni sulla disponibilita' di nuove versioni da scaricare ed installare in modo trasparente e senza disturbare l'utente, che subito salgono agli onori della cronaca notizie sulle prossime evoluzioni di Chrome, il web browser targato Google.
Stando alle ultime presentazioni per il prossimo futuro di tale prodotto si prevede di soppiantare la tendenza prettamente tecnofila di rilasciare le varie versioni identificandole da un numero sequenziale, ed invece impacchettare piccoli cambiamenti ad intervalli regolari e tra loro ristretti (sei mesi) e diffonderli sui desktop del pianeta con un automatismo silenzioso. A ben guardare Chrome da sempre gestisce in questo modo gli aggiornamenti di se' stesso, addirittura compiendo un controllo sul repository centralizzato ogni cinque ore, ma evidentemente il concetto e' stato migliorato e raffinato ulteriormente. Si mormora inoltre che pure la prossima major release di Firefox, la 4 includera' tale funzionalita'.
Come intuibile, appunto, dal post pubblicato l'altro giorno su questo stesso blog questo genere di soluzioni mi garba assai. Tantopiu' per applicativi come i web browser, diventati strumenti essenziali nella vita digitale di ciascuno e cosi' frequentemente bersagliati da attacchi mirati alla loro sicurezza da patchare il piu' presto possibile a prescindere dalla noncuranza dell'utente. Certo chi sviluppa un browser non ha tutta questa urgenza di diffondere nuove features, in quanto in fin dei conti tale classe di software operativo non espone particolari funzionalita' necessariamente sempre nuove (renderizzano le pagine, salvano i bookmarks, aprono e chiudono le tabs, poco altro), ma le migliorie per quanto piccole e discrete son sempre gradite, soprattutto quando non ci si deve attivare in prima persona per ottenerle.
D'altro canto, immagino che nel momento in cui i singoli programmi provvedano per conto proprio all'aggiornamento si possano creare non pochi grattacapi per i packagers delle distribuzioni. Cosa mettere nei repository? Cosa succede se all'atto dell'invocazione di un "apt-get upgrade" la versione proposta e pacchettizzata e' piu' vecchia di quella scaricata autonomamente? Come fronteggiare eventuali aggiornamenti che richiedono librerie e pacchetti particolari, e dunque da installare o a loro volta aggiornare per il supporto di una nuova funzionalita'?
Per non parlare dei futuri (ma comunque non immediati) problemi tecnici che potrebbero sorgere qualora tale pratica dovesse diffondersi: come arginare la potenziale esplosione di comunicazioni verso l'Internet, dovute al fatto che ogni singolo programma pretenderebbe di contatterebbe ad intervalli periodici il proprio server di riferimento in cerca di qualcosa di nuovo da scaricare? E come reagirebbe quella nicchia di utenti cultori della privacy e del pieno controllo dinnanzi alla necessita' di dover disabilitare (o nella peggiore delle ipotesi filtrare con metodi piu' radicali) siffatte transazioni non richieste per ognuno dei software utilizzati?
La soluzione ad entrambi i suddetti tipi di ostacoli potrebbe stare in una evoluzione degli attuali package managers, affinche' forniscano nativamente la funzionalita' di auto-upgrade per i programmi che lo richiedono, coordinando ed ottimizzando le connessioni verso l'esterno e provvedendo un unico centro di configurazione per chi ha il tempo da perdere verificando chi sta facendo cosa. Dirottando tutto al manager centralizzato esso sarebbe sempre consapevole di quale precisa versione e' in uso in un dato momento, quali sono i pacchetti che si auto-aggiornano per fatti propri e quali devono essere allineati con i repository della distribuzione secondo lo schema classico, e come comportarsi con le dipendenze.
Forse adesso e' troppo presto per porsi questo genere di domande, in quanto appunto solo Chrome e Firefox si stanno muovendo verso la direzione dell'autogestione. Ma nel momento in cui dovesse essere osservato un trend piu' cospicuo sarebbe opportuno correre ai ripari il prima possibile, mettendosi d'accordo tutti insieme su come amministrare in modo pacifico la legittima richiesta di aggiornamenti frequenti con la necessita' di far convivere numerosi pacchetti ognuno con una propria sequenza di versioning, ed evitare che codesta emergente moda dilaghi fino a minare uno dei pilastri su cui si poggia il successo del desktop Linux, appunto il package management.
Prevenire e' meglio che curare.

mercoledì 5 gennaio 2011

I Piccoli Aggiornamenti

0 commenti
Tra le attivita' che maggiormente reputo degne di essere completamente delegate alla macchina in modo da non tediare l'utente c'e' sicuramente l'aggiornamento del software installato. Ad oggi qualsiasi distribuzione Linux monta di default un package manager, che si occupa automaticamente di verificare la disponibilita' di nuovi pacchetti e risolve le dipendenze in fase di installazione ed aggiornamento, ma comunque la sua esecuzione dipende dalla volonta' e dall'attenzione dell'utente che o se ne dimentica o viene periodicamente disturbato da notifiche sul suo desktop.
Ad oggi, comunque, l'esecuzione schedulata e silenziosa di un "apt-get update; apt-get upgrade", magari per mezzo di cron, e' assai poco consigliata: troppo spesso accade che tale operazione venga lanciata nel bel mezzo di un update massivo sul repository di pacchetti di riferimento, e se non ci si prende la briga di leggere cosa viene richiesto di fare basta veramente troppo poco per trovarsi, in virtu' di qualche estroso conflitto nelle dipendenze, il desktop environment o qualche driver importante disinstallato.
Ma d'altro canto c'e' un intero universo di componenti software che non sono affatto gestiti (o comunque sono solo marginalmente trattati) dai package manager, e che produrrebbero un danno limitato anche qualora per disgrazia fossero gestiti male: i plugins.
Ogni applicazione evoluta oggi esistente mette a disposizione una ricca API con cui qualsiasi developer puo' aggiungere funzionalita', a volte modeste e a volte molto pesanti, e la tendenza a distribuire in questo modo lo sviluppo tra il maintainer del core principale e gli occasionali partecipanti e' in evidente crescita (forse anche dopo aver constatato l'enorme successo avuto dal concetto di "estensione" applicato al popolarissimo Firefox).
L'unico problema e' che raramente si trovano repository unici di estensioni e plugins destinati ad una specifica applicazione, ed occorre andarsele a cercare appositamente (assumendo ovviamente che se ne conosca l'esistenza). Il mio esempio preferito e' Inkscape: sul sito esiste una raffazzonata pagina dedicata ad indicizzare alcune estensioni esistenti, ma al fondo di essa si trovano tracce di un eventuale progetto strutturato e mirato a tale scopo che risalgono a maggio 2010.
D'improvviso, leggo oggi sul blog di Aaron Seigo il proposito di fornire una sorta di protocollo di auto-discovery per i DataEngines di Plasma (che, detto terra terra, sono delle estensioni di KDE). In sostanza il personaggio descrive uno scenario che io stesso medito da tempo: utilizzare qualcosa come il formato Open Collaboration Services (da me stesso implementato per Gnome) per comunicare ai clients degli utenti variazioni sullo stato dei componenti installati, ed ai fatti provvedere ad una sorta di package management isolato e dedicato ad una nicchia precisa. In un colpo solo si bypasserebbe il management ufficiale delle distribuzioni (che tendono ad essere in ritardo rispetto alle releases dei pacchetti veri e propri), si avrebbe un sistema di aggiornamento unico per tutte le piattaforme, e si estenderebbero le potenzialita' dell'amministrazione di sistema semi-programmatica anche ai frammenti di software sinora bistrattati ed esclusi dalle cure dei packagers.
Per quanto le mire di Seigo siano di molto basso profilo (appunto, limita la sua stessa idea all'aggiornamento dei DataEngines quando potrebbe essere applicato ad ogni genere di estensione), auspico che qualcuno lo stia a sentire e provveda a studiare una soluzione al problema, da poi riutilizzare in altri contesti.
Uno dei piu' grandi vantaggi di Linux rispetto alle altre piattaforme operative e' proprio l'elevato grado di maneggiabilita' dei pacchetti software installabili; tanto vale spremere il massimo da tale concetto, usarlo per dare risalto a sempre piu' opere e farne uno dei canali di penetrazione piu' aggressivi per il software libero.