Open Source on Melabit

Perché open source

Thu, 02 Feb 2017 06:00:00 +0000

Free e open source

Sono da sempre un estimatore della distribuzione del software secondo il modello free o open source e se posso preferisco usare programmi di questo tipo. Anche il mio software pubblico è distribuito secondo licenze di questo tipo (ad esempio questo, appena pubblicato).

Ma perché usare il software free (ad accesso libero) o open source (a sorgente aperto)?¹

Le questioni filosofiche le lascio a personaggi del calibro di Richard Stallman, massimo esponente del movimento del free sofware e fondatore del progetto GNU, e di Eric Raymond, avvocato di un modello aperto ma più vicino agli interessi dele aziende, che hanno descritto in modo egregio i fondamenti di questi modelli di distribuzione del software in due saggi imperdibili, Free Software, Free Society e The Cathedral and the Bazaar (la bibliografia finale rimanda alle versioni italiane di questi volumi).

Leggere il codice

A me interessa affrontare qui una questione molto più spicciola e mostrare come l’accesso al codice permetta di migliorare la qualità del software e di correggerne rapidamente i bachi.

Il concetto di accesso al codice può sembrare campato in aria, riservato solo ad una piccola elite di programmatori esperti. In effetti mettere le mani nel codice è spesso molto più semplice di quanto si pensi e si può fare senza nemmeno essere programmatori esperti o particolarmente dotati.

Ecco una piccola storia pratica e personale. Non è la prima di questo genere che mi succede, ma è quella più recente.

Buttato fuori

Negli ultimi tempi mi sono occupato di sviluppare un sito web quasi istituzionale in Wordpress. La genesi è stata fin troppo lunga – ci sono sempre mille cose da fare ogni giorno – ma alla fine il sito è stato presentato ufficialmente la settimana scorsa.

Per vari motivi non ho sviluppato il sito sul mio Mac, dove avrei potuto usare un sistema di revisione e tenere traccia diretta di tutti i cambiamenti, ma direttamente sul server che ospita il sito. Anzi, per stare sicuro, per lo sviluppo vero e proprio ho usato una copia del sito, sul quale provavo le novità prima di trasferirle al sito principale.

Come è ovvio, gli ultimi giorni prima della presentazione sono stati frenetici, con un sacco di aggiunte e di modifiche dell’ultimo minuto. In questi casi la disciplina va a farsi benedire: non c’era semplicemente tempo di provare ogni cosa sulla copia prima di trasferirla al sito vero e proprio. Ed è chiaro che in questi casi, con una scadenza in vista, c’è un rischio altissimo che succeda qualche guaio all’ultimo minuto.²

Infatti.

All’improvviso, dopo chissà che operazione, sono stato buttato fuori senza complimenti dal mio account di amministratore. Il sito era lì vivo e vegeto, ma di fatto non potevo fare più niente.

Per fortuna potevo almeno accedere all’interfaccia di gestione del server. Da qui la cosa più semplice da fare sarebbe stata quella di ripristinare il sito e il database dall’ultimo backup – fatto ore prima! – cercando poi di ricordare tutto quello che avevo cambiato dopo il backup. Una cosa praticamente impossibile.

Ma per fortuna ci sono i file di log di Wordpress e lì l’errore era stampato chiarissimo, con il nome del file e la riga esatta dove si era verificato il problema. Il colpevole era un plugin di Wordpress che avevo aggiornato poco prima senza patemi. Sembrava inoffensivo: non faceva niente di fondamentale, serviva solo a configurare lo stile grafico del forum del sito.

Worpress è open source e anche i plugin lo sono, quindi il codice è disponibile e si può leggere e modificare a piacere.

Perfino uno come me, con una conoscenza solo basilare di PHP e JavaScript con cui è scritto Wordpress, con un’occhiata veloce poteva capire il motivo dell’errore, una (molto) banale svista del programmatore. Errore che però aveva conseguenze così gravi da impedirmi di lavorare al sito.

Rapida correzione, salvataggio, tutto a posto e in mezz’ora potevo di nuovo entrare nel mio account e tornare lavorare come prima.

Naturalmente sono andato nell’area di supporto del plugin e ho descritto quello che era successo e come avevo risolto il problema. In fondo, se qualcuno ti da un software gratis, è il minimo che si possa fare per sdebitarsi.

Dopo poche ore era uscita la versione aggiornata e corretta del plugin.

Provate ad avere un problema serio con un prodotto commerciale, magari pagato a caro prezzo, e poi ditemi come e in quanto tempo viene risolto. Non ci sarebbe storia.

Bibliografia

Per una volta i volumi citati sopra sono disponibili in italiano. Ho aggiunto anche un bellissimo libro di Sam Williams che tratta della vita e delle ragioni di Richard Stallman nel contesto della cultura hacker degli anni ‘80.

Eric Raymond, La cattedrale e il bazaar, 1998, Apogeo. Disponibile in italiano in una prima versione ridotta rispetto al testo originale aggiornato.
Richard_Stallman, Software libero pensiero libero - Volume primo, Stampa Alternativa, 2003. Disponibile online in formato pdf.
Richard_Stallman, Software libero pensiero libero - Volume secondo, Stampa Alternativa, 2004. Disponibile online in formato pdf.
Sam Williams, Codice Libero (Free as in Freedom, Apogeo, 2010. Disponibile online in formato ePub/Kindle e per iBooks.

Post scriptum

Oltre al senso di libertà, ciò che ho appena descritto è una delle cose più interessanti dell’open source: ci sono così tanti occhi e tanti cervelli con competenze diverse che è normalmente molto facile risolvere i problemi, molto più facile che con un team fisso di sviluppatori, con competenze per forza di cose più statiche.

E poi dai, contribuire a qualcosa senza nemmeno conoscersi, senza avere un interesse economico diretto, fa bene allo spirito e forse anche alla società. Fa meno bene al portafoglio, ma non si può avere sempre tutto.

Le differenze fra il software free e quello open source sono spiegate piuttosto bene in questo breve articolo e, in modo più approfondito, in queste pagine di Wikipedia e WikiWikiWeb. Imprescindibile anche il punto di vista del progetto GNU. ↩︎
Persino il backup a volte non basta: se si fanno modifiche continue, anche perdere un paio di ore di lavoro ripristinando da Time Machine può essere un danno gravissimo. ↩︎

Homebrew: software per il Mac fatto in casa

Tue, 29 Apr 2014 06:00:00 +0000

Homebrew è un sistema di gestione dei pacchetti (package) che semplifica l’installazione su OS X del software open source di derivazione Unix/Linux.

Homebrew si autodefinisce “The missing package manager for OS X” (Il gestore di pacchetti per OS X che mancava), una definizione un po’ sfrontata – in particolare nelle prime fasi dello sviluppo alcuni anni fa – ma ormai non troppo lontana dalla realtà.

La sua semplicità di installazione e di uso l’hanno fatto crescere rapidamente in popolarità nell’ultimo anno, a scapito dei sistemi concorrenti più affermati, Fink e MacPorts (quest’ultimo supportato direttamente da Apple).

A differenza di questi ultimi, Homebrew cerca di usare per quanto è possibile gli strumenti software di base già presenti in OS X – gcc, perl, python, ruby, git, mysql, sqlite – e non obbliga l’utente ad installare duplicati inutili. I package suddetti sono comunque disponibili nell’archivio (repository) di Homebrew, per chi avesse bisogno di utilizzare versioni più recenti (e a volte meno stabili) di quelle utilizzate dalla Apple.

Da qualche mese Homebrew fornisce anche un gran numero di pacchetti precompilati (bottles), velocizzando notevolmente il processo di installazione e di aggiornamento dei pacchetti, che non devono più essere obbligatoriamente compilati uno alla volta.

Questa pagina su Stack Exchange approfondisce i pro e contro dei tre principali sistemi di gestione dei pacchetti su OS X. The state of package management on Mac OS X è una analisi piuttosto approfondita dei pregi e dei difetti di tutti i sistemi di gestione dei pacchetti per OS X, considerando anche quelli meno diffusi e supportati.

Una delle questioni più controverse riguardanti Homebrew riguarda il fatto che tutti i pacchetti sono installati all’interno della cartella (directory) /usr/local/. Alcuni critici osteggiano questa scelta, notando fra l’altro che:

/usr/local/ è una cartella di sistema che non dovrebbe essere usata da Homebrew ma solo dal software installato dall’utente root (l’amministratore onnipotente dei sistemi basati su Unix);
Homebrew modifica i permessi di alcune cartelle contenute all’interno di /usr/local/ assegnandoli all’utente che installa il gestore di pacchetti, mentre i permessi dovrebbero essere configurati in modo che le suddette cartelle siano usabili da tutti gli utenti del sistema;
è da preferire invece la scelta di MacPorts o Fink di usare delle cartelle create ad-hoc, rispettivamente /opt/ o /sw/.

Personalmente mi sembrano critiche risibili e che i vantaggi in termini di praticità e di sicurezza delle scelte fatte dagli sviluppatori di Homebrew superino di gran lunga i presunti svantaggi.

Del resto /usr/local/ e le cartelle in esso contenute sono fatte apposta per installare software specifico per la macchina in uso, vengono usate ad esempio da MacTeX e da Ghostscript, e non capisco cosa impedisca di usarle liberamente anche per altre applicazioni.

Assegnare i permessi di installazione e di uso dei pacchetti di Homebrew ad un singolo utente, piuttosto che a root, limita i rischi di sicurezza che il software installato potrebbe creare nel sistema. Inoltre è difficile negare che il Mac sia un sistema fondamentalmente monoutente, per cui questa scelta dovrebbe comunque andare bene nella maggior parte dei casi.

Nei casi rimanenti di un Mac condiviso da più utenti, indipendentemente dal fatto che ci giri OS X liscio o OS X Server, chi gestisce il sistema dovrebbe essere facilmente in grado di assegnare il gruppo utente giusto a chi è interessato ad usare i pacchetti di Homebrew.

Di sicuro una cosa non più complicata di dover aggiungere al PATH di ciascun utente il percorso della cartella (/opt/ o /sw/ a seconda dei casi) in cui vengono installati i pacchetti gestiti da MacPorts o Fink.

Nel corso del tempo ho usato tutti e tre i sistemi di gestione dei pacchetti, stabilizzandomi da almeno due anni su Homebrew che trovo complessivamente molto più lineare e usabile, senza le troppe opzioni di compilazione di MacPorts, che portano fin troppo spesso a incompatibilità con i pacchetti installati successivamente, o la confusione fra pacchetti binari e sorgenti, con comandi diversi di installazione, di Fink.

Dopo questa lunga introduzione, nel prossimo post vedremo come installare (ma anche disinstallare) Homebrew, ~~esaminando anche i principali comandi di gestione dei pacchetti~~.