Ringrazio sentitamente lo staff e in particolare Gianluigi e colgo l’occasione per invitare gli utenti di MySQL a utilizzare MySQL Italia, uno dei pochi siti ben curati e precisi.

Il nome suggerisce che, nelle intenzioni iniziali di Widenius, l’aspetto su cui il fork si sarebbe dovuto concentrare avrebbe dovuto essere Maria, lo storage engine da lui stesso creato. In realtà MariaDB include anche altri storage engine, sviluppati da terze parti. Vi sono poi alcuni contributi apportati dalla comunità, che in MySQL non sono stati inclusi – probabilmente a causa di procedure troppo rigide, che per la verità non sono state introdotte né da Sun né da Oracle. Ma il lavoro principale degli sviluppatori di MariaDB consiste probabilmente nel migliorare il codice già esistente e quello che viene man mano sviluppato per MySQL, testandolo e correggendo bug e problemi di performance.

La piattaforma primaria per MariaDB è certamente GNU/Linux. In particolare sono stati creati dei pacchetti per varie versioni di Ubuntu, mentre non sono ancora pronti gli RPM per Red Hat e CentOS. Vi sono però i binari per GNU/Linux a 32 e a 64 bit. E’ inoltre scaricabile una versione per Windows che non necessita di installazione. Il sito di MariaDB al momento non menziona la volontà di supportare (o meno) MacOS o altri sistemi UNIX.

Il programma è attualmente in fase beta, quindi non pronto per essere utilizzato in ambienti di produzione. Scaricando l’ultima versione è comunque possibile farsi un’idea abbastanza precisa di come sarà la versione stabile.

La licenza utilizzata è la GNU GPL versione 2, ereditata da MySQL.

Analizziamo di seguito le varie novità di MariaDB rispetto al progenitore MySQL.

Maria

Si tratta di uno storage engine che deriva da MyISAM. Rispetto a quest’ultimo è più performante, soprattutto per quanto riguarda il caching; inoltre può gestire tabelle transazionali. Questa caratteristica sacrifica in parte le performance dei comandi SQL ed è attiva di default quando si crea una tabella. Per creare un’entità non transazionale ma più performante si può usare un’istruzione simile alla seguente:

CREATE TABLE new_tab (…) ENGINE=Maria TRANSACTIONAL=0;

Come per le tabelle MyISAM, le entità Maria non transazionali possono utilizzare il formato FIXED (più performante) o il formato DYNAMIC (richiede meno spazio). Esiste poi il formato PAGE (l’unico disponibile per le tabelle transazionali), ideato per velocizzare il chaching. Tramite la utility maria_pack è possibile generare tabelle compresse di sola lettura, esattamente come si fa con MyISAM.

MariaDB utilizza Maria per gestire le tabelle temporanee create internamente e questo velocizza l’esecuzione di alcune query.

MyISAM, comunque, è ancora presente in MariaDB.

XtraDB

Questo storage engine è un fork di InnoDB sviluppato dalla Percona. Esso incorpora diversi contributi apportati dalla comunità e non presenti nel suo progenitore e, in MariaDB, lo sostituirà.

Allo stato attuale si può notare come l’inclusione di questo engine sia in qualche modo iniziata (ad esempio la presenza della tabella XTRADB_ENHANCEMENTS), ma non è ancora possibile utilizzarlo.

PBXT

PBXT è uno storage engine transazionale sviluppato dalla PrimeBase. Implementa il controllo di versione multipla dei record, che permette di modificare righe delle tabelle senza bloccare l’accesso da parte di altre query, anche durante una transazione. I dati modificati da una transazione vengono scritti su disco una sola volta, in quanto PBXT garantisce l’affidabilità senza che i dati passino prima da un apposito log. Ha inoltre un meccanismo di rilevazione dei deadlock.

I vantaggi di questo storage engine risiedono dunque nelle prestazioni, che possono essere analizzate tramite il tool xstat e la tabella PBXT_STATISTICS nell’INFORMATION_SCHEMA.

Analisi delle prestazioni

E’ stato migliorato lo slow query log, al quale sono state aggiunte numerose informazioni che dovrebbero facilitare l’individuazione dei colli di bottiglia. Sia questo log sia l’istruzione SHOW PROCESSLIST, inoltre, forniscono ora informazioni dettagliate fino al microsecondo (non più al secondo).

Prestazioni e affidabilità

Il sito di MariaDB promette una maggiore stabilità, che deriverebbe anche dalla scelta di eliminare, dove possibile, i warning generati in fase di compilazione.

Abbiamo inoltre un incremento delle prestazioni facilmente rilevabile in almeno un tipo di query scritte male (SELECT che citano nella clausola FROM tabelle non effettivamente utilizzate). E’ infine segnalato un miglioramento prestazionale nella gestione dei thread.

E dopo?

Lo sviluppo di MariaDB, naturalmente, continua. Nel ramo 5.1 dovranno ancora essere inseriti gli storage engine XtraDB, che sostituirà InnoDB, e FederatedX, una evoluzione di FEDERATED, il quale non è più mantenuto. La prossima versione sarà la 5.2.

E’ possibile tenere d’occhio il lavoro svolto dal team di sviluppo grazie al worklog pubblico, che si trova a questo indirizzo: http://askmonty.org/worklog/index.pl

Siti di riferimento

Sito di MariaDB: http://askmonty.org/

Planet MariaDB: http://planetmariadb.org/

Documentazione di Maria: http://dev.mysql.com/doc/refman/5.1-maria/en/se-maria.html

Documentazione di XtraDB: http://www.percona.com/docs/wiki/percona-xtradb:start

Documentazione di PBXT: http://www.primebase.org/documentation/

Valori unici

Cosa significa per un database “questo record esiste già”? Come sappiamo, un record può essere identificato da una o più chiavi, ognuna delle quali può essere un campo, la prima parte di un campo o una combinazione di più campi. Generalmente la Chiave Primaria, che è il modo principale per identificare un record, è costituita da un campo numerico (UNSIGNED INTEGER) chiamato `id`. Vi possono essere delle Chiavi Candidate, che consistono in velori o combinazioni di valori che sono unici per ogni record. In MySQL questi sono i campi che rappresentano gli indici UNIQUE.

INSERT IGNORE

La prima di queste estensioni è la clausola IGNORE dell’istruzione INSERT. Essa semplicemente chiede a MySQL di ignorare gli errori dovuti al tentativo di inserire valori duplicati nella chiave primaria. In altre parole, se si tenta di inserire un record ma esso non può essere scritto poiché contiene un valore unico già presente in tabella, non viene generato alcun messaggio di errore. Se si tenta di inserire diversi record con un’unica INSERT e alcuni di questi non possono essere scritti perchè contengono valori duplicati, gli altri record verranno scritti senza problemi e non viene restituito alcun errore. Spesso i messaggi di errore hanno effetti collaterali che si desidera evitare.
Un’ulteriore possibilità è usare, oltre alla clausola IGNORE, anche la clausola DELAYED. Essa chiede a MySQL di non generare alcun messaggio di errore in nessun caso. Questo vale per gli errori di tipo “Duplicate key”, ma anche ogni altro tipo di errore - ad esempio la mancanza dei permessi necessari per scrivere sulla tabella, disco pieno, etc. Se tale comportamento ci è comunque gradito (perchè non abbiamo intenzione di gestire alcun tipo di errore) allora la clausola DELAYED è da preferire per ragioni di performance. Infatti ciò che rallenta maggiormente le applicazioni sono le comunicazioni di rete e il mancato invio di messaggi di errore che verrebbero comunque ignorati è un’ottimizzazione intelligente. Comunque, è bene ricordare che gli unici Storage Engine a supportare questa clausola sono MyISAM, MEMORY, ARCHIVE e BLACKHOLE. Se usata su tabelle che usano altri motori, DELAYED provoca un errore.

Esempi:

INSERT IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Mario', 'Rossi', '123456');
INSERT DELAYED IGNORE INTO `clienti` (`nome`, `cognome`, `tel`) VALUES ('Maria', 'Bianchi', '654321');

REPLACE

Il comportamento appena illustrato è desiderabile nel caso in cui il record che si tenta di inserire non possa essere più completo di quello già esistente. Se però nel record già presente in tabella alcuni campi sono vuoti (o meglio, impostati ai valori di DEFAULT), anche nel caso in cui l’istruzione INSERT contenga tali valori, essi andranno persi.
Esiste però il caso opposto, cioè quello in cui si presume che il record già presente contenga meno informazioni (o informazioni meno aggiornate) rispetto a quelle che si sta tentando di inserire. In tal caso è ragionevole chiedere a MySQL si inserire sempre e comunque il nuovo record, sostituendo quello che eventualmente potrebbe essere già presente. Per fare questo si utilizza l’istruzione REPLACE.
Essa è una combinazione di DELETE + INSERT. Questo implica alcune conseguenze non del tutto ovvie. La prima riguarda i permessi: per eseguire REPLACE bisogna avere i permessi di DELETE e INSERT. Inoltre, se si esegue REPLACE su una tabella InnoDB (o su altre tabelle che supportano le Chiavi Esterne) prima di inserire il nuovo record si cancellerà il vecchio, scatenando l’evento ad esso associato (come ON DELETE SET NULL). Infine, se sulla tabella sulla quale si esegue una REPLACE esiste un trigger associato all’evento DELETE, questo verrà lanciato.

Esempi:

REPLACE INTO `clienti` SET `nome`='Mario', `cognome`='Rossi', `tel`='123456';
REPLACE DELAYED INTO `clienti` SET `nome`='Maria', `cognome`='Bianchi', `tel`='654321';

Si noti, infine, che REPLACE potrebbe eliminare più di un record prima di inserire il nuovo. Infatti, come si è detto, una tabella può avere più chiavi uniche (PRIMARY KEY e campi UNIQUE) e naturalmente un record potrebbe contenere diversi valori duplicati. Dopo aver lanciato questa istruzione, il numero di affected_rows() restituito corrisponde a 1 (il nuovo record inserito) + il numero di record eliminati. Sapere questo ci permette di determinare facilmente se uno o più record sono stati liminati e quanti:

$deleted_rows = mysqli_affected_rows($con) – 1;

INSERT … ON DUPLICATE KEY UPDATE

Vi è poi un ultimo caso, che è una via di mezzo tra i due precedenti. Può darsi che si voglia inserire un record nel caso esso non sia già esistente, ma che se esso esiste non vogliamo perdere né alcune informazioni già scritte in tabella, né alcune informazioni presenti nell’istruzione. In tal caso si utilizzerà INSERT con la clausola ON DUPLICATE KEY UPDATE.

Vediamo subito un esempio, nel quale tentiamo di inserire un nuovo utente; se esso esiste, vengono modificati il suo indirizzo email e l’url del suo blog, lasciando però inalterate tutte le altre informazioni.

INSERT INTO `utenti` (`username`, `password`, `email`, `www`)
VALUES ('pippo', 'sesamo', 'pippo@topolinia.com', 'pippo.noblogs.org')
ON DUPLICATE KEY UPDATE `email`='pippo@topolinia.com', `www`='pippo.noblogs.org';

INSERT … ON DUPLICATE KEY UPDATE non può essere utilizzata con DELAYED, sebbene ciò non generi alcun errore. E’ possibile inserire diversi record come si fa talvolta con le INSERT anche utilizzando la clausola ON DUPLICATE KEY UPDATE. Il numero di affected_rows() equivale al numero di record inseriti + (il numero di record modificati * 2). Questo implica che non è possibile sapere con esattezza quanti record sono stati aggiunti e quanti sono stati modificati basandosi esclusivamente su affected_rows().

VENENUX dichiara che non includerà mai pacchetti non liberi. Il sistema ha come primo obiettivo quello di essere fortemente ottimizzato. L’equipo che si occupa del suo sviluppo non è costituito solo da programmatori, ma anche di esperti di vari settori che sono in grado di stabilire i requisiti da soddisfare per venire incontro ai bisogni degli utenti avanzati. Inoltre il tutto è preconfigurato per adattarsi meglio a un’utente latinoamericana.

Con queste premesse, entra nella schiera delle distribuzioni libere un sistema operativo che non solo è libero dal punto di vista formale, ma favorisce una buona quantità di utenti che sono normalmente sono ignorati per motivi geopolitici.

http://www.kongoni.co.za/

• Le distribuzioni completamente libere riconosciute dalla Free Software Foundation:
  http://www.gnu.org/distros/free-distros.html
• Linee guida per valutare la libertà di una distribuzione:
  http://www.gnu.org/philosophy/free-system-distribution-guidelines.html
• I motivi per cui le distribuzioni più note non sono incluse nell’elenco:
  http://www.gnu.org/philosophy/common-distros.html

Kongoni (che in lingua shona significa gnu) è una distribuzione basata su Slackware con desktop KDE. Ancora non compare nell’elenco ufficiale della FSF, che però ha terminato di esaminare l’ultima release, chiamata Nietzsche e rilasciata meno di due settimane fa. Gli unici pacchetti non liberi che sono stati trovati sono il firmware Ralink e i font Lucida - nel prossimo update del sistema verranno eliminati. Kongoni si impegna inoltre a eliminare qualsiasi altro pacchetto non libero che venga loro segnalato.

Essendo una distribuzione sudafricana, in futuro hanno intenzione di includere alcuni software liberi che la maggior parte delle altre distribuzioni (libere o non libere) non può includere per problemi di brevetti o altre questioni legali che però in Sudafrica non sussistono.

Spero che a qualcuno venga voglia di contribuire. Non fatevi intimidire dall’inglese. Prima di tutto, credo che i contributor più attivi non siano madrelingua inglese. E poi c’è sempre bisogno di una traduzione in italiano - anche se fosse parziale e aggiornata di rado sarebbe meglio di niente.

Buona rivolta.

Il termine copyleft è chiaramente il contrario di copyright. La traduzione italiana (contestata) è permesso d’autore. Ma che cosa significa?

Il copyright sono i “diritti” dell’autore di un’opera, intesi come divieti per chi ne possiede una copia. La famosa frase “All rights reserved” (tutti i diritti riservati) rende abbastanza ovvio l’ossimoro: non si parla di diritti, ma di rigide imposizioni.

Il copyleft è una clausola che può essere applicata a una licenza libera. Quest’ultima garantisce le libertà basilari all’utente. Tra queste libertà vi è quella di distribuirla. Il problema nasce proprio qui: se io scarico un software libero, ho il diritto di:

• Distribuirlo come software non libero?
• Aggiungervi moduli non liberi?
• Integrarlo in un software non libero di cui sono proprietario?

Personalmente penso che la risposta alle domande sopra poste debba sempre essere no. Per lo stesso motivo per cui si sviluppa software libero, bisognerebbe impedire che tale software venisse distribuito non liberamente o andasse a integrare altri software che liberi non sono.

Altri la pensano diversamente. Ritengono che impedire le tre azioni sopra elencate equivalga a privare gli utenti di alcune loro libertà. A questa obiezione rispondo che non bisogna abusare della parola libertà. La mia libertà inizia dove finisce la tua? Bene, allora non ho il diritto di prendere un software (scritto da me o da altri), fornirtene una copia e decidere cosa farai tu con quella copia. Che senso ha lagnarsi di “non essere liberi di imporre”? E’ pura retorica.

Ad ogni modo non tutti la pensano così e non riuscirò, con questo post, a convincerli a rivedere le proprie idee. Con questa introduzione voglio principalmente spiegare cos’è il copyleft: è il “copyright al contrario” che impedisce di distribuire un software libero (o i suoi moduli) come software non libero.

L’uso del programma in rete

Le licenze, con o senza copyleft, hanno un problema storico. Come ho spiegato in un post precedente, le licenze libere tradizionali sono state scritte anni prima della diffusione di internet come la conosciamo oggi. Di conseguenza esse garantiscono tutte le libertà fondamentali agli utenti che ricevono una copia del programma, che avranno quindi la possibilità di eseguirlo in locale o installarlo essi stessi su di un server. Quando utilizzano il programma attraverso una rete però (webmail, forum, mailing list…) non ricevono alcuna copia del programma e i termini della licenza non si applicano. Queste persone non vedono il codice sorgente, tanto meno lo possono modificare o ridistribuire. Eppure, da un punto di vista logico, non esiste un motivo per il quale chi usa Evolution debba avere più libertà di chi usa una webmail.

L’unica licenza che prende in considerazione questo problema, e che quindi garantisce a chi usa un programma attraverso la rete le sue libertà basilari, è la GNU AGPL. Si tratta di una licenza libera dotata di un forte copyleft, derivata dalla GPL.

Al momento, chi non ama il copyleft non ha a disposizione una licenza già pronta che risolva i problemi legati all’uso di un programma in rete. Vi è però una motivazione: inserire una clausola che garantisca le libertà degli utenti di rete significherebbe inserire una forma di copyleft. Infatti non si garantirebbe solo la libertà di chi riceve il programma che si sta distribuendo, ma anche la libertà degli utenti del suo server.

Chi considera una regola simile inaccettabile, a mio parere, dovrebbe comunque garantire in prima persona almeno i diritti degli utenti dei propri siti internet. Nulla gli vieta infatti di distribuire i sorgenti di tutti i programmi liberi che crea o che utilizza, se la licenza lo consente.

Le licenze senza copyleft

La più famosa licenza priva di copyleft è indubbiamente la BSD. Quando si utilizza questo nome però bisognerebbe capire cosa si intende. Esistono infatti due versioni: la licenza BSD a 4 clausole (o licenza BSD originale o FreeBSD license) conteneva la cosiddetta clausola pubblicitaria (ad clause). La clausola numero 3 imponeva infatti di includere nel software una frase che riconoscesse la paternità del programma alla This product includes software developed by the University of California, Berkeley and its contributors. Non si tratta ovviamente di un abuso, ma questo ha portato il problema della proliferazione dei riconoscimenti. Poichè ogni autore di un “pezzo” di software tendeva a modificare questa licenza aggiungendo il proprio nome o quello della propria organizzazione, man mano che nuovi programmatori miglioravano il codice si aggiungevano sempre più nomi. Lo stesso FreeBSD ha deciso di eliminare quella clausola e tentare di eliminare i nomi che potevano essere eliminati quando, nel 1997, ha dovuto rilasciare una versione con ben 75 riconoscimenti. Va comunque detto che non vi è nulla di non libero in tale licenza, solo qualche problema pratico.

La versione successiva della licenza viene generalmente chiamata la BSD a 3 clausole, o modificata. La clausola publicitaria è stata depennata. Questa licenza, in pratica, permette a chi riceve una copia del software di farne ciò che desidera. Anche distribuirlo in forma binaria - purchè naturalmente applichi la stessa licenza.

La licenza X11 non obbliga l’utente a includere il nome dell’autore originale (l’X Consortium) ma al contrario impedisce l’uso di tale nome a fini pubblicitari, a meno che non si disponga di esplicita dichiarazione scritta da parte dell’interessato.

La SGI Free Software License B, versione 2.0, è molto simile alla X11. Le versioni precedenti alla 2.0 non sono considerate libere. Tuttavia esse permettono di ridistribuire il software con una versione successiva della licenza, perciò la loro non-libertà si può annullare ni maniera banale.

La licenza Expat permette essenzialmente di fare qualsiasi cosa con il software che copre, purchè non si elimini la licenza. Inoltre essa si applica esplicitamente anche ai file di documentazione distribuiti con il programma.

Sia la licenza X11, sia la Expat sono talvolta chiamate licenza MIT. Data l’ambiguità del termine sarebbe meglio evitarlo.

Come si combinano queste licenze con la GPL e la AGPL?

Tutte le licenze senza copyleft qui elencate sono compatibili con la GPL. Questo significa che il codice coperto da GPL e il codice libero coperto da queste licenze possono essere combinati insieme formando un’unica entità distribuibile, modificabile e ridistribuibile. Ogni parte di codice sarà sottoposto solo alle regole stabilite dalla licenza alla quale è associato.

Queste licenze sono compatibili anche con la AGPL. Si tenga presente che un modulo coperto da una di esse, se inserito in un software più ampio coperto da AGPL, viene sottoposto a una delle clausole della AGPL. Se modificato, quindi, il suo codice sorgente dovrà essere reso disponibile alle persone che se ne servono attraverso una rete.

Differenze con la GPL

La AGPL3 differisce con la GPL3per principalmente per la sezione 13. La riporto, in inglese, perchè GNU non ha ancora fornito una traduzione in italiano.

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU General Public License into a single
combined work, and to convey the resulting work.  The terms of this
License will continue to apply to the part which is the covered work,
but the work with which it is combined will remain governed by version
3 of the GNU General Public License.

Per prima cosa, essa dice che, se si modifica il codice sorgente del programma, bisogna offrire ai propri utenti (che interagiscono con il programma attraverso la rete) la possibilità chiara (prominently) di ricevere una copia dei sorgenti stessi.

La AGPL e le altre licenze

Il codice sorgente del programma rilasciato con la AGPL potrebbe includere delle librerie o altri moduli, che possono anche essere stati scritti da altri programmatori, e che potrebbero essere coperti da licenze differenti. Allora sorge la domanda: se si modifica queste librerie, occorre poi distriburle agli utenti che le utilizzano attraverso una rete?

Risposta: si, a meno che non si tratti di librerie di sistema. Non sarebbe ragionevole, infatti, chiedere che chi modifichi libc ne fornisca il sorgente agli utenti del proprio sito. Tuttavia, se si utilizza una libreria per la connessione al database e questa viene modificata, i sorgenti dovranno essere pubblicamente disponibili.

Per la precisione, la sezione 13 utilizza una definizione ben precisa parlando del “codice sorgente” che deve essere distribuito: lo chiama Corresponding Source. Questo termine è definito nella sezione 1 della AGPL:

The “Corresponding Source” for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.  However, it does not include the work’s
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work.  For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.

The Corresponding Source for a work in source code form is that
same work.

AGPL e GPL: compatibili?

La AGPL3 richiama esplicitamente la GPL nella sezione 13 riportata all’inizio. Essa è compatibile con la versione 3 della GPL. Questo significa che è possibile usare una libreria distribuita con GPL3 all’interno di un programma AGPL.

Tuttavia, la AGPL non è compatibile con la GPL2. Questo accade perchè quanto richiesto dalla sezione 13 è definito come Further Resctrictions dalla sezione 7 della GPL2. Essa proibisce qualsiasi ulteriore restrizione, perchè si rischierebbe che un distributore aggiunga alla licenza imposizioni che non hanno a che fare con la libertà.

Scegliere tra AGPL e GPL

La maggior parte degli sviluppatori web che rilasciano script coperti da licenza AGPL3, semplicemente non hanno riflettuto sul fatto che questa licenza non garantisca realmente la libertà degli utenti o non sono a conoscenza della AGPL.

La AGPL andrebbe sempre utilizzata al posto della GPL. Nel caso in cui si stia rilasciando uno script PHP che produce output in HTML, le ragioni sono ovvie. Ma anche quando si sta rilasciando un programma di altro genere è saggio utilizzare la AGPL. Infatti il software potrebbe essere scaricato da programmatori che decideranno di migliorarlo, eventualmente aggiungendovi nuove funzionalità - questa pratica è prevista dalle licenze libere ed è da incoraggiare. Tuttavia questo significa anche che un programma pensato per essere eseguito in locale potrebbe diventare un programma che offre funzionalità di rete, che magari l’autore originale non immaginava. E’ quindi una buona abitudine utilizzare sempre la AGPL.

Troppo libera per Google

Google si proclama sostenitore del software libero e fornisce strumenti per alcuni progetti. Google Code però ha preso una decisione drastica: ha bandito la AGPL. Chiedendo gentilmente agli autori dei progetti coperti da questa licenza di… andarsene.