10 anni di Git: un’intervista al creatore Linus Torvalds

Più di 10 anni fa, la community di sviluppo del kernel Linux si trovò dinanzi un problema: il sistema di controllo delle versioni BitKeeper aveva interrotto la loro licenza e nessun altro sistema andava più bene per i loro bisogni. Linus Torvalds, il mitico creatore di Linux, prese la situazione in mano e sparì per un intero weekend per riemergere la settimana seguente con Git. Oggi Git è sicuramente il sistema più usato e richiesto nella gestione delle versioni.

Noi abbiamo dedicato un’intera e completa guida a Git e sul come gestire le versioni del software. Se siete qui per imparare, dategli uno sguardo!

Per celebrare questo traguardo, il sito Linux.com ha intervistato Linux Torvalds chiedendogli qualche storia behind-the-scenes e in generale cosa ne pensa dello stato attuale del progetto. Noi vi riportiamo qui questa intervista, tradotta integralmente.

Perché hai creato Git?

Non ho mai davvero pensato e voluto realizzare un sistema di gestione dei sorgenti, e penso che sia la cosa meno interessante in tutta l’informatica (con la possibile eccezione dei database). Ho odiato tutti i sistemi profondamente. Ma poi BitKeetper è arrivato e ha cambiato questa visione che avevo del controllo di versione. BitKeeper ha la maggior parte delle funzioni necessarie e in più offre il merge tra il repository locale e quello remoto ed è davvero una gran cosa. Il fatto che il controllo fosse distribuito ha fatto sparire di colpo i vecchi problemi che avevano gli altri sistemi e tutta la questione del “chi può cambiare cosa”. Mostrò che tutto questo poteva essere evitato semplicemente facendo lavorare ognuno su un repository locale. Certo, aveva i suoi problemi: c’erano alcune scelte tecniche che causavano problemi (rinominare i file era terribile), ma il principale lato negativo era il fatto che siccome non era open source, c’erano un sacco di persone che semplicemente si rifiutavano di usarlo. Così, mentre diversi sviluppatori usavano BitKeeper (perché è gratuito per i progetti open source), non era usato da altri. Ci ha molto aiutato nello sviluppo del kernel, ma resistevano piccoli punti da risolvere.

Si arrivò a un punto quando Tridge (Andrew Tridgell) cominciò a fare il reverse-engineering del (relativamente) semplice protocollo di BitKeeper, cosa che era contro le norme d’uso del software. Ho passato diverse settimane (ma a me sono sembrati mesi) provando a fare da mediatore tra Tridge e Larry McVoy (il capo di BK, ndr) ma alla fine la cosa non funzionò. Così ad un certo punto ho deciso di non poter continuare a utilizzare BK, ma neanche di voler tornare ai tempi bui pre-BK. Tristemente, al tempo, anche se c’erano altri sistemi che provavano ad implementare la logica del software distribuito, nessuno lo faceva davvero bene, soprattutto in remoto. Anche le performance che volevo nel trasferimento dati in remoto non erano soddisfacenti, e inoltre ero preoccupato dell’integrità del codice. Così ho semplicemente deciso di scrivere un sistema nuovo.

Qual è stato il tuo approccio? Sei stato sveglio tutto il weekend o l’hai scritto in orario di lavoro?

Heh. Puoi vedere da te come ha preso forma guardando la storia del repository di Git stesso. C’è voluto circa un giorno per arrivare ad essere “self-hosted” così da poter usare Git per sviluppare.. Git. Il primo giorno quindi, i commit erano, diciamo, nascosti, ma tutto era già lì. Ho lavorato maggiormente durante il giorno, ma se guardate ci sono due istantanee fatte verso la mezzanotte e un paio alle 2. La parte più interessante però è sul quanto velocemente ha preso forma; il primo vero commit nel repository non contiene molto codice, ma poteva già eseguire il commit di se stesso. Il vero trucco però è sul come organizza i dati.

Ho provato a stressare il sistema fin tanto che prendeva forma in circa 10 giorni (a quel punto ho provato a fare il mio primo commit del *kernel*), ma non sono finito nella pazzìa del programmare senza sosta. Infatti la prima versione è abbastanza piccola, non è composta da molto codice, perché tutto dipendeva dal fatto che l’idea base fosse buona. Ci avevo pensato su per un po’ prima che l’intero progetto iniziasse. Avevo visto i problemi che altri avevano. Avevo visto quello che volevo evitare.

Ha raggiunto le tue aspettative? Come sta funzionando oggi secondo te? Ci sono limitazioni?

Sono molto contento di Git. Funziona notevolmente bene per il kernel e sta ancora soddisfacendo tutte le mie aspettative. Quello che mi sembra interessante è il modo in cui è stato adottato da così tanti altri progetti. Sorprendentemente veloce. C’è molta resistenza nel cambiare il sistema di controllo della versione, basta guardare quanto tempo CVS e anche RCS sono rimasti in giro, ma ad un certo punto Git ha preso il sopravvento.

Quale pensi sia il motivo di questa grande diffusione?

Penso che molti altri si siano sentiti frustrati dagli stessi problemi che mi hanno fatto odiare SCM e, sebbene ci siano stati molti progetti che tentassero di risolvere uno o due piccoli casi che facevano impazzire la gente, non c’era veramente niente di simile a Git che davvero affrontasse di petto questi problemi. Anche se molti non capirono l’importanza della parte riguardante la logica “distribuita” (e molti la contrastavano), una volta che si resero conto che ciò consentiva backup semplici e affidabili e che tutti potevano avere i propri repository di test privati senza preoccuparsi di alcuna politica sui permessi del “chi fa cosa”,  adottarono Git senza voltarsi indietro.

Git durerà per sempre o prevedi un altro sistema fra altri 10 anni? Sarai ancora tu a scriverlo?

Non lo scriverò io, no. E forse vedremo qualcosa di nuovo in dieci anni, ma vi garantisco che assomiglierà sicuramente a Git. Non che Git sia perfetto, ma ha realmente aggiustato tutti i problemi basilari degli altri sistemi.

Nessuna falsa modestia 😉

Perché Git funziona così bene per lo sviluppo di Linux?

Beh, è ​​stato ovviamente progettato per il nostro flusso di lavoro, quindi è parte di esso. Ho già citato molte volte l’intera parte “distribuita”, ma vale ripeterla. È stato anche progettato per essere abbastanza efficiente per un progetto grandicello come Linux, ed è stato creato per fare cose che la gente considerava “difficili” prima di Git – perché queste sono le cose che anche *io* faccio ogni giorno.

Giusto come esempio: il concetto di “fusione” tra rami viene generalmente considerato qualcosa di complesso e difficile nella maggior parte degli SCM. Si dovevano pianificare i merge con calma, perché potevano essere distruttivi. Questo per me non è accettabile, dal momento che quotidianamente faccio decine di merge e il problema a cui devo dedicarmi è testare il risultato del mio codice, non perdere tempo sul merge stesso. La “parte Git” del mio lavoro dura giusto un paio di secondi, di solito ci vuole di più solo per scrivere la spiegazione del merge. Quindi Git è stato fondamentalmente progettato e scritto per i miei requisiti, e si vede.

Molte persone sostengono che Git è solo per persone super intelligenti. Anche Andrew Morton ha detto che Git è “espressamente progettato per farti sentire meno intelligente di quello che tu pensi di essere.” Qual è la tua risposta a questo?

Penso che sia stato vero in passato, ora non più. Ci sono diverse ragioni per le quali le persone si sono sentite così, una sola però è rimasta: “puoi fare le cose in tanti modi”.

Puoi fare molte cose con Git perché molte funzioni sono state create per lavorare insieme ad altre persone. Git comprende un set di strumenti molto potenti e spesso all’inizio ci si può sentire sopraffatti, però questo offre anche il vantaggio che la stessa operazione si può fare in modi diversi, e tutti “funzionano”. Generalmente il modo migliore di imparare Git è iniziare con comandi molto semplici e non guardare neanche le altre funzioni finché non si è abbastanza bravi con le basi.

Ci delle ragioni storiche per le quali Git è stato spesso considerato complicato. Una di queste è che è stato davvero complicato. Le persone che hanno iniziato a usare Git molto presto (per lavorare sul kernel), hanno dovuto apprendere davvero un insieme molto scomodo di script per far funzionare tutto. Questo perché tutto lo sforzo all’inizio fu indirizzato per far funzionare “la tecnologia di base” e poco per renderlo semplice. Così Git (meritatamente) si è fatto una brutta fama all’inizio, perché dovevi sapere esattamente cosa stavi facendo. Tutto questo è stato vero soltanto per i primi sei mesi, forse un anno.

L’altro grande motivo che ha fatto pensare che Git fosse difficile è che Git è molto diverso dagli altri sistemi. Ci sono molti sviluppatori che hanno usato CVS (o altri) per un decennio o due. Git non è CVS, neanche lontanamente. I comandi sono diversi. Non abbiamo neanche immaginato di farlo simile a CVS, anzi il contrario. E se hai usato un sistema CVS-like per molto tempo, è ovvio che Git possa apparirti complicato e stranamente diverso. Perché le mie versioni sono basate su un HEX da 40 caratteri e non su una stringa tipo “1.3.1.”?

Git però non è “inutilmente diverso”. Le differenze sono necessario. È solo che ha fatto alcune persone pensano che sia più complicato di quanto lo sia perché provengono da un background molto diverso. La fortuna è che là fuori molti programmatori non hanno neanche mai usato CVS, e il loro prima sistema è proprio Git.

Pensi che lo sviluppo del kernel Linux sarebbe potuto crescere così rapidamente senza Git? Perché sì o perché no?

Beh, “senza Git” di sicuro. Ma avrebbe richiesto che qualcun altro, prima o poi, avesse creato qualcosa di equivalente: un sistema di controllo delle versioni distribuite efficace proprio come Git. Avremmo sentito certamente il bisogno di qualcosa *come* Git.

Qual è la tua opinione su GitHub?

GitHub è un eccellente servizio di hosting. Non ho niente contro. Ora, le lamentele che ho avuto riguardo GiHub come piattaforma di sviluppo- ovvero fare commit, pull, tenere traccia dei bug, etc. – sono che non funziona molto bene per tutti. Non è nemmeno vicino, purtroppo, neanche per il kernel: è troppo limitato.

Questo è in parte a causa del modo in cui il kernel viene sviluppato, ed in parte è dovuto al fatto che certe interfacce di GitHub incoraggiano i cattivi comportamenti. I commit fatti su GitHub, per esempio, hanno messaggi scritti male, proprio perché l’interfaccia non blocca questa prassi. Fixando questi dettagli il tutto lavorerà sicuramente meglio, ma difficilmente sarà  appropriato per il kernel linux.

Qual è l’utilizzo più interessante che hai visto per Git e/o GitHub?

Sono contento che abbia reso così facile avviare un nuovo progetto. L’hosting è sempre stato un punto ostico, e con Git e GitHub è quasi banale creare un piccolo progetto dal nulla. Non importa quale sia il progetto: quello che conta è che tu lo puoi fare.

Hai progetti laterali, attualmente? Magari un software ancora più brillante che dominerà lo sviluppo del software per gli anni a venire?

Niente di programmato. Ma vi terrò aggiornati.

Disponibile l’aggiornamento a WordPress 4.7.4

Dopo quasi 60 milioni di download per la versione 4.7, il team WordPress ha annunciato l’uscita della versione 4.7.4, che è segnato​ come un aggiornamento di manutenzione, che risolve cioè piccoli problemi e non introduce novità sostanziali.

Queste piccole modiche sono 47 e tra loro vi sono fix per l’incompatibilità con la prossima versione del browser Chrome e l’editor, alcune inconsistenze nella gestione dei media e piccoli aggiornamenti delle API REST interne

Per l’elenco completo delle modifiche, consultate la lista completa delle modiche.

Per scaricare questo aggiornamento scaricate direttamente WordPress 4.7.4 

Oppure andate in Bacheca → Aggiornamenti e cliccate su “Aggiorna ora”. Se avete abilitato gli aggiornamenti automatici, questo update è in arrivo su tutti i sistemi.

Importare backup di un database da riga di comando

Abbiamo visto come fare un backup di MySQL o MariaDB con mysqldump nell’articolo dedicato ed ottenere un backup pronto in un semplice file .sql che possiamo manipolare, o semplicemente mettere da parte come archivio.

Quando vogliamo importare questo backup, ripristinando le tabelle presenti, possiamo facilmente eseguire il comando mysql.

La sintassi del comando base, da usare nella shell, è:

Vediamo, un esempio utilizzando le credenziali di accesso al database:

In questo esempio stiamo importando il backup nel file backup.sql nel database NOME_DATABASE. Sarà necessario specificare l’utente UTENTE_DATABASE che ha i permessi di accesso al NOME_DATABASE e la password che va indicata senza mettere lo spazio, esempio: -pPASSWORD_DATABASE.

Non avendolo specificato nel comando, di default mysql proverà a connettersi al database attivo su localhost.  Per importare il dump su un database remoto rispetto alla macchina su cui eseguiamo il comando, dobbiamo specificare l’hostname del server remoto con l’opzione --host=HOSTNAME_DATABASE:

Dato che ci apprestiamo a eseguire lo spostamento di un file via internet, vi consiglio di usare l’opzione -C (maiuscolo!) che effettuerà la compressione dei dati durante il loro trasporto.

Se avete particolari esigenze di importazione, sono disponibili molte altre opzioni sulla documentazione ufficiale.

Buon backup!

Esportare un database da riga di comando con mysqldump

mysqldump è un programma molto utile per effettuare un backup logico di uno o più database MySQL o MariaDB. Tutto quello che fa è esportare una successione di query (come INSERT INTO ..) leggendo rigo-per-rigo le tabelle e scriverle in un file .sql che può essere poi importato in seguito in un altro database. Naturalmente con mysqldump possiamo scegliere anche un formato diverso, come CSV o XML: uno dei vantaggi è che, avendo un singolo file, possiamo modificarlo prima di importarlo o prima di effettuare qualche test.

A livello di performance, fare un backup con mysqldump non è un processo che impegna a fondo la CPU perché usa un single thread. Significa, cioè, che possiamo effettuare un backup anche con un server in produzione, anche sotto carico pesante senza problemi.

Backup di un singolo database

La sintassi del comando base, da usare nella shell, è:

Vedremo, in questo articolo, vari esempi per diverse condizioni di utilizzo. Ricordiamoci che sarà sempre necessario fornire l’username e la password dei database che stiamo esportando.

In questo esempio stiamo effettuando il backup del database NOME_DATABASE. Da notare che è necessario specificare l’utente UTENTE_DATABASE che ha i permessi di accesso al NOME_DATABASE e la password che va indicata senza spazio -pPASSWORD_DATABASE.

Non avendolo specificato nel comando, di default mysqldump si connetterà a localhost.

In questo caso, nel file backup.sql avremo un backup completo.

Backup di tutti i database

Nel caso vogliamo fare il backup di tutti database possiamo indicare l’opzione --all-databases:

Backup di database selezionati

Nel caso vogliamo fare il backup di più database possiamo indicare l’opzione ---databases seguita dai nomi dei database separati da spazio:

Backup di un database remoto

Negli esempi precedenti abbiamo dato per scontato che il server fosse localhost, in sostanza abbiamo eseguito mysqldump sullo stesso server su cui si trova il database. Ci viene data, però, la possibilità anche di eseguire il backup di un database remoto. Questo è molto utile quando vogliamo, per esempio dal nostro computer, eseguire velocemente il backup di un database che si trova, appunto, in remoto e avere il file già sul nostro computer. Per farlo, è sufficiente specificare l’hostname del server con l’opzione --host=HOSTNAME_DATABASE:

Attenzione: è necessario che il server database accetti connessioni dall’esterno!

Anche se i tre casi proposti copriranno probabilmente il 90% delle vostre esigenze, sono disponibili molte altre opzioni sulla documentazione ufficiale.

Buon backup!

Prevenire l’hotlinking delle immagini con .htaccess

La protezione degli hotlink non permette agli altri siti di richiamare le nostre immagini direttamente dal nostro server. Questo avviene perché nel codice del sito chiamante viene richiamato direttamente l’URL di un file che ospitiamo sul nostro server. Se non aggiungiamo alcuna protezione, l’hotlinking è automaticamente permesso. In molti casi questo può essere considerato un abuso delle nostre risorse.

Hotlink protection totale

Per bloccarne l’hotlink delle immagini possiamo aggiungere delle semplici regole al file .htaccess:

Queste regole in sostanza intercettano tutte le richieste ai file che terminano in .jpg, .jpeg, .gif, .png e, nel caso NON vengano dal nostro sito, il nostro sistema non risponde. Ovviamente dovremo sostituire NOSTRO_DOMINIO.IT con il nostro dominio reale.

Permettiamo l’hotlink da uno o più domini

Se, rispetto al caso precedente, volessimo permettere ad un qualche sito esterno di accedere, come un partner o un nostro sponsor, possiamo specificare a quali domini è permesso fare l’hotlinking delle nostre immagini:

In questo esempio abbiamo aggiunto una regola a quella precedente, che permette alle richieste provenienti da ALTRO_SITO.IT (che naturalmente dobbiamo sostituire con il dominio reale) di non essere bloccate. Possiamo replicare questa regola per più domini, usandola più volte e indicando per ogni riga un dominio diverso.

Mostriamo un’immagine

Volendo, anziché bloccare totalmente le richieste alle nostre immagini, possiamo servire all’utente che approfitta delle nostre risorse un’immagine predefinita no_hotlink.jpg.

Evitare l’hotlinking dei file javascript con .htaccess

Uno dei classici problemi dei tanti copia-incollatori seriali di internet, è che – magari a loro insaputa – incollano pure gli indirizzi dei nostri script. A tutti gli effetti richiedono questi file javascript direttamente dal nostro server e in sostanza abusano delle nostre risorse. Questo fenomeno è chiamato hotlinking e possiamo aggirarlo facilmente. Magari pure essendo un po’ cattivi.

Uno dei casi più diffusi è sicuramente quello delle immagini, per il quale potete leggere l’articolo su come prevenire l’hotlinking delle immagini. Un secondo caso, dicevamo, è quello dei file javascript. Per bloccarne l’hotlink è sufficiente aggiungere una regola nel file .htaccess come questa:

Naturalmente è necessario sostituire NOSTRO_DOMINIO.IT con il nostro dominio reale. Queste regola, in sostanza, significa:

[Se il chiamante è diverso da vuoto ed è diverso dal nostro dominio, con o senza www, e il file richiesto termina con .js, non rispondere alla richiesta]

A tutti gli effetti, quindi, il sistema non invierà il file al chiamante. Ma c’è una variante un po’ più cattivella, certamente più divertente! Potremmo, anziché non rispondere come nell’esempio precedente, servire un file javascript specifico.

Come vedete, abbiamo modificato l’ultimo rigo, dicendo al sistema di servire il file hotlink.js, nel quale possiamo decidere di mettere questo codice:

Appena qualcuno proverà a fare un hotlink di un nostro file javascript, il browser dell’utente verrà reindirizzato al nostro sito.

Ottimizzare le prestazioni di MySQL e MariaDB con MySQLTuner

Non appena abbiamo fatto il setup di un nuovo server, è necessario spesso effettuare un controllo sulle prestazioni del server MySQL, MariaDB o Percona installato sulla macchina. Ottimizzare la scrittura delle tabelle, la cache e tutti i piccoli errori di configurazione può portare anche ad un significativo incremento di prestazioni. Ricordiamo, inoltre, che le configurazioni di default possono non essere sicure!

Per effettuare un controllo sistematico, possiamo usare il MySQLTuner, uno script open source scritto in Perl che effettua una lunga lista di controlli  (circa 300) sul database installato sul nostro server, tra i quali:

  • Informazioni di sicurezza e accesso
  • Confronto della versione installata sul server con un database di bollettini di sicurezza per capire se è vulnerabile
  • Controlla cache, indici e connessioni
  • Controlla slow queries e performance di join e altre operazioni comuni

Questo script NON modifica alcuna configurazione. Si tratta di uno script di sola lettura che analizza e vi suggerisce le impostazioni più veloce e sicure. Sta a noi, eventualmente, modificare la configurazione del server e beneficiare dei consigli.

Come detto, è uno script in perl, pertanto è necessario scaricare un singolo file più due file aggiuntivi che contengono rispettivamente un dizionario delle password non sicure e una lista di vulnerabilità note.

Eseguiamo questi comandi nella shell:

A questo punto eseguiamo lo script:

Otterremo a schermo una lunga lista di valutazioni segnate da un [OK], se la configurazione è corretta, e [!!] dove lo script ci suggerisce che ci sarebbe bisogno di un qualche aggiustamento.

Ecco ad esempio una serie di raccomandazioni che MySQLTuner ci indica:

Modifichiamo la configurazione di MySQL o MariaDB

Proviamo ad applicare qualche consiglio che lo script ci indica, nello specifico, proveremo a modificare questi valori:

  • wait_timeout sotto 28000
  • query_cache_size maggiore o uguale a 8M
  • innodb_file_per_table settato a ON

Per prima cosa, troviamo il file my.cnf, che si troverà in posizione diversa a seconda del sistema. Generalmente, si trova in /etc/mysql/my.cnf oppure /etc/my.cnf. Apriamo il file con un qualsiasi editor, nel nostro caso vim

Modifichiamo le variabili come suggerito e, se non esistono, aggiungiamole al file.

Una volta salvato il file my.cnf, riavviamo MySQL o MariaDB per applicare la nuova configurazione:

Per verificare che i nuovi setting siano applicati possiamo rilanciare MySQLTuner: non dovremmo trovare i parametri appena modificati tra i suggerimenti.

Prestashop: risolvere il problema delle immagini non visualizzate

Uno dei problemi fastidiosi e diffusi che possiamo incontrare quando lavoriamo con Prestashop, è quello delle immagini degli articoli che non vengono visualizzate correttamente. Stiamo parlando di un problema che riguarda soltanto le immagini, perché di fatto tutti gli altri URL (come prodotti o categorie) funzionano correttamente, ma rimane il problema delle immagini che non si vedono.

Questo avviene perché Prestashop non usa l’indirizzo diretto alle immagini, ma ne riscrive gli URL. Per prima cosa accertiamoci che le immagini siano effettivamente presenti sul server nella cartella img  presente nella directory di installazione.

Una delle cause all’origine del problema è che Prestashop ha qualche problemino di funzionamento quando viene ospitato su un server su cui gira nginx. Se usiamo invece Apache, i redirect per creare i Friendly URL funzioneranno correttamente senza configurazioni aggiuntive.

La soluzione sta nel dire direttamente a nginx come deve eseguire l’url rewrite per quanto riguarda le immagini, incollando queste direttive nel suo file di configurazione nginx.conf:

Sostituite /CARTELLA_INSTALLAZIONE/ con il nome della vostra cartella. Se Prestashop fosse installato nella cartella principale (root) del vostro dominio, basterà sostituire /CARTELLA_INSTALLAZIONE/ con /:

Se non avete accesso al file di configurazione o non sapete come fare, contattate la vostra hosting company: saprà sicuramente aiutarvi al meglio.