sabato 30 novembre 2013

Microkernel(s)

Quite often I find on the web threads related to the "microkernel" cutlure versus the "monolithic" kernel one.
First of all, I have to say I'm not an expert in the former, but I would like to provide some insights from what my experience has been so far about the two approaches.

Please consider we are not really and strictly talking about Operating Systems kernels here: the approach can be extended to pretty much every complex software system.
So what is a microkernel architecture? Essentially it is a complex system made up by small pieces that cooperates and coordinates each other; each component is pluggable and can be substituted without a whole system reboot or downtime. The key point here is that EVERY component can be replaced/upgraded at run-time without having to stop the system as a whole.
In order to achieve this run-time behavior, the system must provide a strong decoupling of modules via a kind of message-passing scheme, and therefore we could state that the messaging delivery system is the only one that is going to require a whole reboot when changed.

The most famous Operting System based on microkernel is Minix, but this is only a huge example of this kind of architecture. OSGi is another example of a dynamic system where pretty much everything can be plugged at run-time. STREAMS, the old SunOS networking layer was also based on such concept. Erlang reminds me a microkernel architecture.

Are microkernel systems good or bad? It depends. When the task has to be low level, microkernels are generally bad. As an evidence of this, even if Minix is still under active development, all the rest of the world has chosen another approach, and I believe that if great OSs like FreeBSD, OpenBSD, Linux have chosen and still continue to resist to microkernel, they cannot be totally wrong.
STREAMS have been kicked off as soon as the network load increased, due to the performance lack.
On the other hands, OSGi is very succesfull, being the system not a low level one. The same role/agents systems I developed during my research activity could have been thought of a microkernel kind of systems, and while they were very dynamic, performances were not so good as a statically bound system.

So what?
If dynamism and pluggable features are the most important parts of your project, go for a microkernel approach. If performance is your aim, avoid a microkernel.
This is my personal opinion.

mercoledì 27 novembre 2013

Editor di testi

Aron Seigo ha pubblicato un interessante post nel quale parla della sua "conversione" da Vim a Kate, l'editor di default dell'ambiente KDE (per chi non lo sapesse, Seigo e' stato il leader dello sviluppo della versione 4 di KDE).
Tre sono fondamentalmente le motivazioni del passaggio da Vim a KDE: (i) scorciatoie simili, (ii) la possibilita' di avere delle sessioni, ossia una sorta di project management per gruppi di file e (iii) la console integrata.

L'aspetto degli editor mi tocca sempre profondamente, anche perche' l'editor di testi e' effettivamente lo strumento piu' usato da uno sviluppatore software (e anche dai sysadmin). Francamente sono abituato a Emacs e tendo a vedere negativamente ogni altra possibilita'. Si tratta certamente di una mia inclinazione e preferenza, ma Emacs e' a tutti gli effetti uno di quegli strumenti che mi permette di fare tutto e, cosa non trascurabile, funziona su qualunque piattaforma io debba lavorare. E con piattaforma non intendo solo il sistema operativo/architettura, ma anche il sistema grafico (che potrebbe anche essere assente).
Purtroppo Emacs sta diventando, a mio avviso, sempre piu' un sistema per abitudinari, e questo fara' si che molte delle feature interessanti non vengano portate su Emacs facilmente.
Tuttavia continuo ad essere molto soddisfatto di Emacs, che fino ad ora mi permette di avere una interfaccia unificata verso file system, sviluppo di software, editing di testo e shell.

Questione di gusti.

lunedì 25 novembre 2013

Addio e grazie per tutto il pesce

Mi è sembrata la citazione migliore per salutare Charlie.

domenica 17 novembre 2013

Disabilitare un indice in PostgreSQL

Ho gia' scritto in precedenti post come PostgreSQL sia un database fortemente orientato al catalogo: ogni azione che il database esegue e' fortemente dipendente dal catalogo di sistema.
Anche gli indici usabili lo sono, ed essere a conoscenza di come disabilitare temporaneamente un indice puo' risultare molto importante. PostgreSQL infatti non mette a disposizione, per scelta, i "query hints", ovvero non e' possibile specificare con quale indice PostgreSQL deve forzatamente eseguire una query. Come conseguenza, a volte puo' risultare molto complicato valutare l'efficacia di un indice, e spesso il modo che si usa e' quello di disabilitare, a livello di intero cluster, alcuni metodi di accesso. Ma ecco che tramite il catalogo di sistema e' possibile inibire un singolo indice al fine di escluderlo dalle scelte possibili dell'ottimizzatore, e quindi di valutare gli indici rimanenti.

Per prima cosa si crei un semplice use case fatto da una sola tabella piena di tuple casuali:

CREATE TABLE people( name text,
surname text,
pk serial not null,
primary key(pk) );
INSERT INTO people( pk, name, surname )
SELECT generate_series(1, 100000),
md5( random()::text ),
md5( random()::text );

Si passi poi alla creazione di due indici sui campi della tabella:

CREATE INDEX name_idx ON people(name);
CREATE INDEX surname_idx ON people(surname);

E' ora possibile verificare che uno dei due indici viene usato in query sufficientemente filtranti:

EXPLAIN SELECT surname, name FROM people WHERE surname like 'f%';
QUERY PLAN
-----------------------------------------------------------------------------
Bitmap Heap Scan on people (cost=21.54..967.48 rows=500 width=64)
Filter: (surname ~~ 'f%'::text)
-> Bitmap Index Scan on surname_idx (cost=0.00..21.42 rows=500 width=0)
Index Cond: ((surname >= 'f'::text) AND (surname < 'g'::text)) 


 Il catalogo di sistema pg_index fornisce informazioni circa la disponibilita' degli indici su ogni tabella, e quindi e' possibile ottenere lo stato "attuale" degli indici per una tabella specifica con una query simile alla seguente:

SELECT cc.relname, indexrelid, indnatts, indisclustered, indisvalid, indisready FROM pg_index JOIN pg_class c ON c.oid = indrelid JOIN pg_class cc ON indexrelid = cc.oid WHERE c.relname = 'people' AND c.relkind = 'r' AND cc.relkind = 'i'; 

relname | indexrelid | indnatts | indisclustered | indisvalid | indisready -------------+------------+----------+----------------+------------+------------ people_pkey | 16541 | 1 | f | t | t 
name_idx | 16558 | 1 | f | t | t 
surname_idx | 16559 | 1 | f | t | t 

La colonna indnatts indica quanti attributi della tabella fanno parte dell'indice; la colonna indisclustered indica la cluster-ness dell'indice, o meglio se la tabella e' ordinata in base a questo indice. La colonna indisvalid e' quella forse piu' importante: indica se l'indice e' usabile dall'ottimizzatore, o meglio se usabile in modo "sicuro". In altre parole, un valore false in questa colonna indica che l'indice al momento non deve essere preso in considerazione perche', ad esempio, una operazione di INSERT/UPDATE sulla tabella e' ancora in corso e a seguito di questa l'indice deve essere riorganizzato. L'ultima colonna mostrata, indisready, indica se l'indice e' pronto a subire modifiche, ossia puo' essere aggiornato a seguito di modifiche nella tabella che referenzia. Da quanto descritto sopra si puo' concludere che indisvalid contribuisce a dare "visibilita'" e "validita'" all'indice, e quindi valori false nelle colonne indicano a PostgreSQL di ignorare l'indice. E' facile verificare quanto appena detto disabilitando un indice nel catalogo di sistema (ammesso che sia super utente): 


UPDATE pg_index SET indisvalid = false WHERE indexrelid = 16559; e il piano di esecuzione ora cambia: EXPLAIN SELECT surname, name FROM people WHERE surname like 'f%'; QUERY PLAN ------------------------------------------------------------ 
Seq Scan on people (cost=0.00..2485.00 rows=500 width=64) 


Con questa semplice modifica al catalogo e' quindi possibile verificare altri indici, scartati a priori dall'ottimizzatore, senza intaccare il funzionamento dell'intero cluster. Si noti che l'ottimizzatore di PostgreSQL e' molto bravo nel fare il suo lavoro, e quindi se ha deciso di scartare altri metodi di accesso e' quasi certo che questi ultimi siano poco efficienti. E' possibile verificare il comportamento degli indici anche a seguito di una operazione di UPDATE: 

EXPLAIN UPDATE people SET surname = 'TEST' WHERE surname like 'f%'; QUERY PLAN ------------------------------------------------------------------ Update on people (cost=0.00..2485.00 rows=500 width=42) -> Seq Scan on people (cost=0.00..2485.00 rows=500 width=42)
Filter: (surname ~~ 'f%'::text)

e riabilitando l'indice si ottiene che questo viene nuovamente usato:

UPDATE pg_index SET indisvalid = true WHERE indexrelid = 16559;
EXPLAIN UPDATE people SET surname = 'TEST' WHERE surname like 'f%';
QUERY PLAN
-----------------------------------------------------------------------------------
Update on people (cost=21.54..967.48 rows=500 width=42)
-> Bitmap Heap Scan on people (cost=21.54..967.48 rows=500 width=42)
Filter: (surname ~~ 'f%'::text)
-> Bitmap Index Scan on surname_idx (cost=0.00..21.42 rows=500 width=0)
Index Cond: ((surname >= 'f'::text) AND (surname < 'g'::text))

What is (for me) Open Source?

A few weeks ago I was doing an interview about the past PGDay.IT, the national event related to PostgreSQL; the very last question of such interview was about my understanding of Open Source.
Well, it is not simple to give a quick answer to this question, and therefore I try to write down some thoughts about what I believe it is the Open Source.

My opinion is that Open Source is not fully related to writing code and programs, it is more a mindset. Open Source means curiosity, the will to learn something more, to understand how a piece of the world is working.
Everyone, at least one time in his whole life, has opened some piece of hardware: the computer, the VHS, the car hood, a lamp, and so on. This is the Open Source mindset: curiosity to explore how something become a working thing. And this curiosity is what makes  a professional: the need to understand something more, that will help him to acquire new knowledge and, therefore, to be able to apply such knowledge in his day-by-day work.

The above is the real important part of Open Source: it is a culture, not a technique!

Now, Open Source has also several myths, the most common one being that since the "code" is open, it can be audit by so many users and experts that is has to be 100% correct.
This is not my opinion.
First of all, complex code requires very high skills and context knowledge, and therefore it does not mean anything releasing the code as Open Source if only a few people are able to "understand" such code.
Second, being available to everyone does not mean that anyone is interested in reading the code.
Therefore, Open Source code is not a silver bullet for quality, but rather a starting point to get new ideas (let's call the branches) and new improvements from other people.

What about the money? Well, Open Source is generally cheaper than proprietary software, and this is often good except when the management start thinking that if it does not cost anything it means it is not worthing at all (a quite common mindset in my opinion). The key point here is different: it is not the fact that Open Source does not cost anything, it does cost, but often for related services. That is: "take this software and use if for free, and if you need some assistance please hire me and I will help". Does it mean that the for-free version is a low quality one? It depends on who is making it available for free, but generally it is not.

Last but not least, a small thought: does really exist proprietary software? After all, almost every software is created, maintained and improved by different programmers, that means there are several people knowing how the software works. And this makes the software not-proprietary, or better, proprietary to other people. In other words, there is not a real proprietary software, there are only people giving up their rights.

sabato 16 novembre 2013

MySQL Workbench e "safe mode"

MySQL Workbench ha una funzione a mio avviso estremamente irritante: viene impedito l'UPDATE o la DELETE di tuple che non siano referenziate tramite la loro chiave.
Altri programmi seguono approcci simili, ma piu' razionali. Ne e' un esempio l'autocommit (che anche lo stesso MySQL Workbench implementa): di fatto si richiede all'utente di fare un commit esplicito al termine di uno statement per prevenire l'accidentale perdita/modifica di dati.
Ma il "safe mode" usato da MySQL Workbench che previene UDPATE/DELETE con query che non referenzino le chiavi e' molto piu' fastidiosa: di fatto si costringe l'utente ad andare nelle impostazioni del programma per cambiarne il comportamento, cosa che non puo' quindi essere agilmente modificata in una sessione di lavoro che preveda piu' query.


Apprezzo lo sforzo di MySQL di impedire errori accidentali e frettolosi, ma onestamente penso che questa ennesima feature anti-DBA non ponga a favore dell'ecosistema stesso.

venerdì 15 novembre 2013

KMail, KDE e la directory della posta

Ormai sono piu' di 10 anni che uso fedelmente KDE come desktop environment.
Mi piace, funziona bene, mi trovo bene, e anche se ne esistono di piu' leggeri e semplici, lo preferisco a molti competitor anche commerciali.
La mia passione per il programma di posta elettronica, KMail, si e' andata affievolendo negli anni. Non che il programma abbia perso in qualita', ma semplicemente mi sono mosso verso un approccio maggiormente Web per riuscire a tenere ordine fra tutti i computer che uso. Insomma, un po' piu' di cloud.
Ma uso ancora KMail, e fino ad ora non avevo mai avuto problemi. Fare il backup della posta era una operazione semplice e quasi indolore, e in linea con la filosofia Unix si trattava di poco piu' che un tarball ben assestato.
Eppure nelle ultime versioni di KDE/KMail qualcosa e' cambiato, e in modo anche abbastanza silenzioso oserei dire.
La cartella della posta di un utente non risiede piu' in ~/Mail, come ci si potrebbe aspettare, ma in una cartella nascosta ~/.local che il KDE usa appunto per lo storing dei dati delle applicazioni.

Nulla in contrario, basta sapere cosa si deve cercare, ma onestamente penso che la scelta sia idiota (e difficilmente mi sentirete mai dare addosso a KDE!).

Anzitutto KDE ha gia' una cartella privata, che e' ~/.kde, e quindi non vedo l'esigenza di averne una differente. Ma anche ammesso che questo sia un modo per tenere configurazioni e dati separati, approccio piu' che comprensibile, non vedo perche' creare una cartella nascosta ~/.local. E ancora di piu' non capisco come mai ~/.kde non abbia un link a ~/.local in modo da permettere almeno un salvataggio dei file attraverso i link.
Mi ricorda molto l'approccio Microsoft Windows con la "Application Data" in ogni home utente.

La morale di quanto scritto sopra? Fare sempre un backup accurato dell'intera directory home!
Non si puo' sbagliare.

PostgreSQL su Amazon RDS

Sono molti i post che indicano la novità in casa Amazon RDS, ossia il supporto a PostgreSQL 9.3.1, come riportato ufficialmente:

Amazon RDS supports DB instances running PostgreSQL 9.3.1. You can create DB instances and DB snapshots, point-in-time restores and backups.

Si noti che Amazon permetteva già l'uso di PostgreSQL in EC2, ma l'accettazione di PostgreSQL nel Relational Database Service (RDS) rappresenta una vera innovazione.
Inoltre pare che la versione usata da Amazon sia un vero e proprio fork di PostgreSQL.

Cinque volte cinque

Qualche giorno fa, mentre ero fermo attendendo il pieno di carburante, ho notato una cosa curiosa sul contachilometri della mia macchina.


martedì 12 novembre 2013

PostgreSQL e uso dello spazio di storage

PostgreSQL tenta di minimizzare, o meglio di ritardare il piu' possibile, gli accessi allo storage fisico. In questo port voglio mostrare come anche una operazione apparentemente banale come la cancellazione di una colonna da una tabella non produca immediati effetti su disco.
 
Per prima cosa occorre creare una tabella di esempio da popolare con un po' di dati di prova per valutare come cambi l'uso dello storage secondo le modifiche alla struttura della tabella stessa:

CREATE TABLE dropping_test( pk SERIAL NOT NULL, description text, PRIMARY KEY(pk) );



WITH RECURSIVE counter(pk) AS
( SELECT 1 UNION SELECT pk + 1 
  FROM counter WHERE pk < 1000000 )
INSERT INTO dropping_test(pk, description)
SELECT c.pk, 'A fake description for entry ' || c.pk
FROM counter c;



La query di cui sopra vuota la tabella e la riempie di un milione di tuple sostanzialmente identiche. La dimensione finale della tabella risulta essere di circa 60 MB:

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) );
pg_size_pretty
----------------
65 MB


A questo punto si puo' procedere alla rimozione della colonna description, che e' quella che occupa la maggior parte dello spazio di storage essendo formata da testo libero. Da notare che dopo la rimozione della colonna il catalogo di sistema mostra l'attributo (colonna) come "deprecato". Cio' significa che l'attributo e' stato eliminato logicamente dalla tabella ma non fisicamente (poiche' ancora presente nel catalogo di sistema).


ALTER TABLE dropping_test DROP COLUMN description;
ALTER TABLE
Time: 92.774 ms


Da notare la velocita' di eliminazione (logica) della colonna: di fatto non e' successo molto sullo storage, e quindi il sistema non ha perso tempo nel rimuovere la colonna.
Una colonna rimossa diventa sostanzialmente invisibile al parser, ossia non e' usabile lato SQL. Se si interroga il catalogo di sistema si ottiene l'informazioni circa la rimozione della colonna, che pero' ha perso il proprio nome (il drop di una colonna non e' una operazione recuperabile):

SELECT attname, attisdropped FROM pg_attribute a JOIN pg_class c ON a.attrelid = c.oid WHERE c.relname = 'dropping_test';

attname | attisdropped
------------------------------+--------------
tableoid | f
cmax | f
xmax | f
cmin | f
xmin | f
ctid | f
pk | f
........pg.dropped.2........ | t


In realta', se e' vero che si e' perso il nome della colonna, si ha qualche informazione circa la sua posizione: il nome nel catalogo degli attributi riporta la posizione ordinale della colonna appena eliminata. In altre parole, 'pg.dropped.2' indica che e' stata eliminata la colonna numero 2 della tabella, come si puo' evincere dal file sorgente heap.c:

/*
* Change the column name to something 
* that isn't likely to conflict
*/
snprintf(newattname, sizeof(newattname),
"........pg.dropped.%d........", attnum);


E la tabella, dal punto di vista fisico, come e' cambiata? Di fatto non e' cambiata, visto che lo storage non e' stato toccato:

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) ); pg_size_pretty
----------------
65 MB


A questo punto si puo' far intervenire vacuum per vedere cosa succede lato fisico e logico; in particolare il processo di vacuuming andra' a riscrivere le pagine dati rimuovendo lo spazio occupato dalla colonna rimossa. Il risultato, al termine dell'operazione, e' una riduzione della dimensione della tabelle e la scomparsa dell'attributo droppato nel catalogo di sistema:

VACUUM FULL VERBOSE dropping_test;
INFO: vacuuming "public.dropping_test"
INFO: "dropping_test": found 0 removable, 1000000 nonremovable row versions in 8334 pages
DETAIL: 0 dead row versions cannot be removed yet.
CPU 0.61s/0.53u sec elapsed 2.29 sec.
VACUUM
Time: 4593.219 ms

Che ci porta ad avere una tabella "compressa":

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) );
pg_size_pretty
----------------
31 MB



Si presti attenzione: tutto questo e' stato possibile perche' autovacuum era disabilitato:

SHOW autovacuum;
autovacuum
------------
off

Se autovacuum fosse stato attivo, come normalmente e', la riorganizzazione della tabella sarebbe avvenuta quasi subito e quindi la dimensione della tabella sarebbe cambiata sotto al naso dell'operatore.

Si noti che l'operazione inversa, l'aggiunta di una colonna, si comporta sostanzialmente in modo analogo: quando viene aggiunta una colonna il sistema memorizza nel catalogo la disponibilita' della nuova colonna, ma non opera sullo storage.

ALTER TABLE dropping_test ADD COLUMN description text;
ALTER TABLE
Time: 19.337 ms

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) );
pg_size_pretty
----------------
31 MB

E si noti anche che la scrittura di una tupla non implica la riorganizzazione di tutta la tabella: di fatto, grazie ad MVCC, le tuple "nuove" sono in append sui dati e quindi le tuple "vecchie", prive di colonna aggiunta, non vengono riorganizzate:

UPDATE dropping_test 
SET description = 'Hello World' WHERE pk = 1;

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) );
pg_size_pretty
----------------
31 MB

Discorso differente se si aggiunge una colonna con valore di default, cosa che forza il sistema a scrivere il valore di default su ogni tupla e quindi ad invalidare ogni tupla vecchia con conseguente raddoppiamento delle tuple e aumento di spazio:

ALTER TABLE dropping_test 
ADD COLUMN description_initialized text 
default 'A fake description as default here!';
ALTER TABLE
Time: 4356.180 ms

SELECT pg_size_pretty( pg_relation_size( 'dropping_test' ) ); pg_size_pretty
----------------
65 MB

In conclusione, PostgreSQL cerca di utilizzare lo storage fisico in modo molto efficiente ritardando il piu' possibile le scritture (o riscritture) su disco. Ancora una volta si evince come il comportamento di PostgreSQL sia molto guidato dal catalogo di sistema.

domenica 10 novembre 2013

PGDay.IT 2013: una cosa che mi sono scordato

Il PGDay.IT 2013 è stato un vero successo, ormai è fuori discussione.
Nelle settimane seguenti ho avuto la possibilità di realizzare due interviste, una in italiano e una in inglese, sull'andamento dell'evento e della community ITPUG.
Le interviste sono state fatte a me, ma ci tengo a precisare che il lavoro dietro al PGDay.IT 2013 e ad ITPUG non è solo farina del mio sacco, bens^ di tutti gli amici e colleghi del consiglio direttivo nonché dei soci volontari.

In questi giorni stiamo anche pubblicando le video interviste realizzate all'evento. Guardando quella relativa ad ITPUG Lab, che ritrae me e Gianluca, mi è tornata in mente una cosa che non ricordavo piu': la stanchezza di quella giornata maturata durante i preparativi all'evento.
Ma la soddisfazione supera di slancio qualche ora di sonno persa!



Cara Trenitalia....

Cara Trenitalia,
sono sempre io, un viaggiatore che nonostante tutti i maltrattamenti ricevuti continua a prenotare biglietti con la speranza di riuscire a usare i tuoi mezzi.
Ammetto pero' che nell'ultimo periodo mi hai messo a dura prova.
Ebbene si, perche' mi obblighi ad acquistare i biglietti prima usando un sistema Web di dubbia funzionalita', al fine di poter usufruire degli sconti il cui solo scopo sembra quello di farmi sentire uno stracciano, visti tutti i "warning" che compaiono e che mi indicano di scegliere una tariffa piu' costosa.
Mi forzi ad arrivare puntuale, anzi in anticipo, per poter prendere posto in treni sporchi e, molto spesso, sudici.
E nonostante questo, io che ancora accetto e preferisco di viaggiare in treno, sono pure maltrattato.

Negli ultimi sei mesi mi sono recato due volte a Prato, quindi un viaggio (Modena-Prato) di circa 1,5 ore. Entrambe le volte ho prenotato degli Intercity, che mi pare di capire siano treni di tutto rispetto. Ma sui 4 viaggi complessivi, solo uno e' stato puntuale, e negli altri casi ci sono stati ritardi rispettivamente di 10 minuti, 30 minuti e 45 minuti.

Ora comprenderai, cara Trenitalia, che piu' di 30 minuti di ritardo su un treno che ne dura circa 90 sono inaccettabili. E ovviamente diritto al rimborso, stando al tuo fantastico sistema Web di prenotazione e gestione, neanche a parlarne!

Ma diciamo pure che sono stato io sfortunato, e che ho scelto due giornate particolarmente sfortunate, seppur feriali.
Altri treni quindi viaggeranno sicuramente con maggiore puntualita'!
Non e' pero' il caso del famigerato "Gigetto", collegamento Modena-Sassuolo. Si, lo so che ufficialmente quello e' un treno RTPER e non Trenitalia, ma non sono molto esperto e me un "treno" vale l'altro. Tanto piu' che i treni TPER transitano nelle stazioni Trenitalia, le quali si scordano di avvisare i viaggiatori TPER di eventuali disguidi tecnici.
Su tutti i monitor luminosi si vedono infatti informazioni circa treni TPER in partenza, e una voce metallica dall'altoparlante non fa che ricordarci che se non saliamo subito sul treno lo perderemo...ma il treno non e' sui binari! E arriva, con calma, 25 minuti dopo. O vogliamo forse ricordare le innumerevoli volte che il treno viene sostituito dall'autobus, che aspetta esattamente 1 minuto oltre l'orario ufficiale prima di partire dal piazzale piu' lontano di tutta la stazione?

Insomma, cara Trenitalia, ma perche' ogni tanto non provi anche tu a viaggiare con i tuoi stessi mezzi per vedere se il servizio e' veramente cosi' soddisfacente?

sabato 9 novembre 2013

Room Number 621: EuroBSDCon!

I attended the Euro BSD 2013 in Malta, on the last week of September.


The conference was a great mix of technical and social knowledge and represents a great opportunity to meet, talk and learn directly from the /Unix-gods/ of any time and nation. For instance, I was sitting near the legendary McKusick while listening the great Theo De Raadt during his keynote about the time_t overflow problem.

I had the great opportunity to see and meet people I've only seen as names on mailing lists, and the technical quality of many of the talks was really good. Several talks were related to the [[http://www.openbsd.org][OpenBSD]] project, and I have to say I'm every day more interested in this project more for its policy than for its technology; but this is another story.

I had nothing but good words to say about the event and the organization, and definetely was worth being there.
I had also the opportunity to visit (again) Malta, which is a very nice place to be and to spend a few days.

venerdì 8 novembre 2013

Room Number 236: PGDay.IT 2013

PGDay.IT 2013: un successo!


Non saprei come altro iniziare questo post relativo alla conferenza annuale dedicata a PostgreSQL. E' chiaro, sono di parte, anche perche' ormai faccio parte del comitato di organizzazione dalla prima edizione, e quindi da 7 anni.
Ma il successo di questa edizione e' stato proclamato a gran voce dai partecipanti, come e' giusto che sia.
Sia chiaro, non e' stato un PGDay.IT perfetto, sono stati commessi alcuni errori, ma il risultato complessivo e' stato ottimo.



Tante le novita' introdotte con questa edizione, fra le quali spicca il primo ITPUG Lab, e lasciatemelo dire, era ora!
 Il Lab e' stata una sessione parzialmente derivata dall'OST che ha "spinto" i partecipanti a mettere le mani su problemi e tematiche concrete, da loro stessi proposte, in un ambiente collaborativo ove vari team si applicavano per il raggiungimento di uno scopo. Finalmente una sessione realmente aggregante e soprattutto non passiva! E a detta dei partecipanti l'idea (non totalmente mia) e' stata una piacevole e utile novita'.

Altra grossa novita' il live streaming, che penso abbia contribuito sia a far conoscere ed apprezzare PostgreSQL che l'ottimo lavoro di ITPUG.

La conferenza e' stata tenuta da speaker professionali e preparati, e il contenuto tecnico e' stato eccellente. Ospiti d'onore Bruce Momjian (che fra gli altri ha fatto anche il discorso di apertura) e David Fetter.

La partecipazione e' stata da record: 91 persone.
L'associazione ha ritrovato vigore e nuovi soci si sono uniti alla famiglia ITPUG.
La birra non e' mancata, grazie anche agli amici che hanno sponsorizzato l'evento; anche la Fiorentina non e' stata risparmiata e scherzando posso dire che ormai ogni anno la riunione degli "elefanti" provoca la morte di qualche innocente mucca...

Sono fiducioso che tutto lo staff e i componenti ITPUG continueranno a lavorare bene.
Al momento sono ancora molto preso dalla conclusione lavori, e quindi non ho il tempo e le energie per fornire un resoconto piu' dettagliato dell'evento.