venerdì 19 agosto 2011

FreeBSD vs Linux: chi è il piu' grasso?

Non è mia intenzione dare un confronto tecnico e dettagliato dei due sistemi operativi, perché non sarebbe possibile (FreeBSD è un sistema completa, Linux un kernel) e anche perché non voglio influenzare nessuno con le mie opinioni.
Però un confronto della code base dei due progetti è possibile e anche abbastanza semplice da fare (grazie a numerosi tools automatici). Ebbene confrontando il kernel 3.0.3 di Linux con il sistema 8.2 di FreeBSD si ottengono i seguenti risultati:

  • linee di codice: Linux ~ 9.8 milioni; FreeBSD ~ 10.1 milioni
  • linee di commento: Linux ~ 2.1 milioni ; FreeBSD ~ 2.6 milioni
  • file: Linux ~ 32 mila ; FreeBSD ~ 34 mila
Ne consegue che FreeBSD è il sistema piu' grosso, in tutti i sensi. Da notare però che il code-style è differente nei due progetti, e infatti FreeBSD "ruba" qualche linea di codice poiché la dichirazione delle funzioni ha una signature che si estende sempre piu' righe (sempre una con il tipo di ritorno e spesso i parametri sono in stile ANSI-C), mentre Linux tende ad usare una riga sola.
Tanto per dare un termine di paragone, si pensi che un progetto come PostgreSQL ha un code base di circa 1 milione di linee (formattate come FreeBSD)!

Cosa si evince da questi numeri? Assolutamente nulla se non la dimensione pachidermica dei due sistemi e l'impossibilità per un normale umano di conoscere ogni angolo e ogni pezzo di codice di anche solo uno dei due kernel. Ad ogni modo si tenga presente che la dimensione non sempre conta, e quindi avere progetti "grassi" non implica che questi siano per forza lenti o inadeguati; l'unica cosa che ciò implica realmente è che è sempre piu' complicato mantenere una tale base di codice (diff, peer review, ecc.).

Qt: il protocollo signal/slot

Il compilatore moc produce un file speciale, moc_nomeclasse.cpp (e il relativo compilato), per ogni file sorgente che includa segnali e/o slot. Analizzare e debuggare il codice in esecuzione è un buon esercizio per comprendere cosa il sistema Qt faccia dietro alle quinte.
Per questo ho creato due classi molto semplici, una Signal con tre semplici segnali:

void integerSignal(int emittingValue);
void voidSignal();
void floatSignal(float emittingFloatValue);

e una classe Slot con i relativi slot (e le loro semplici implementazioni):


// slot per ricezione di un segnale
// che accetta un parametro intero
void Slot::integerSlot(int emittedValue){
printf("\nSegnale intero ricevuto %d\n", emittedValue);
}
// slot per la ricezione di un segnale senza argomenti
void Slot::voidSlot(){
printf("\nSegnale void ricevuto\n");
}


Anzitutto, osservando i file prodotti dal moc compiler, si nota che gli oggetti sono identificati da una stringa che identifica anche i nomi simbolici degli slot/signal presenti (e i relativi nomi simbolici dei parametri):

//moc_signal.cpp
static const char qt_meta_stringdata_Signal[] = {
"Signal\0\0emittingValue\0integerSignal(int)\0"
"voidSignal()\0emittingFloatValue\0"
"floatSignal(float)\0"
};

// moc_slot.cpp
static const char qt_meta_stringdata_Slot[] = {
"Slot\0\0emittedValue\0integerSlot(int)\0"
"voidSlot()\0"
};

La prima parte della stringa rappresenta una sorta di intestazione, ovvero indica se quello che segue è relativo a segnali o slot.

mercoledì 10 agosto 2011

FLAP is now available as Open Source

A few days ago I created a repository on GitHub to host a few bits of source code: Ferrari Luca's Agent Platform (FLAP). This tiny project is a Java agent platform inspired by Aglets that I used during a course I did at the University of Modena and Reggio Emilia in late 2006. My idea was to present students with a simple agent platform, easy to understand and to debug, in order to make they understand the main concept behind concurrency, thread management and agent messaging a platform must accomplish. The platform represents also a good starting point to do experiments against agent algorithms and theories, and it is for this reason I'm releasing this as Open Source. You are free to experiment and improve the platform as much as you want, but please take into account that the platform is intended to be a didactic workbench, not a professional or complex product. The code compiles with Apache Maven, and if you run test you will actually prompted with a micro interactive shell.

The code is released under the BSD license, so you are really free to do whatever you want with it. But if you find it useful in your courses, studies, free time, please let me know.


mercoledì 3 agosto 2011

L'importanza di "permanently" quando unito a "delete"...

Può sembrare banale, quando si cancella qualcosa questa dovrebbe sparire.
Per sempre.
Eppure nell'era dei social network, molti sistemi non cancellano propriamente il dato, lo rendono solo non piu' pubblico. Alzi la mano chi sta pensando a Facebook.
Ebbene identi.ca ha un comportamento un po' piu' onesto: cancella definitivamente quello che l'utente vuole eliminare. Le parole, specialmente quelle non scritte, sono molto importanti.

PostgreSQL l'inaffondabile

E' sempre difficile convincere i non utenti PostgreSQL delle capacità di questo fantastico prodotto, penso che la pigrizia e la paura di cambiare siano i motivi che frenano il passaggio a PostgreSQL. Se ogni database facesse bene il proprio mestiere e implementasse correttamente la teoria (transazioni, WAL, rollback, replica,...) e gli standard i prodotti sarebbero realmente interscambiabili, ma si sa che il mondo non è fatto di cose uguali.
Fa molto piacere allora trovare dei messaggi come questo che riportano il caso di diversi database colpiti dalla stessa sventura, nello stesso momento, nello stesso luogo e con gli stessi DBA (e quindi con le stesse competenze). Sembra che PostgreSQL sia così buono da permettere realmente di dormire sonni tranquilli:

Complete power failure
(the stand-by generator took fire) in one small datacenter (around 500
machines). We had Oracle, SQL Server, DB2, MySQL, Progress, and of
course PostgreSQL. The only database engine that restarted with no
operation required was PostgreSQL. There were very minimal problems with
Oracle (typing recover on some instances), but we had quite a few
problems with the other engines.