Java Actors and the missing FIPA

Java Actors are becoming a well known way to build distributed, parallel, message-passing based applications. The theory behind actors is very similar to that behing agents, even if an agent more complex than an actor because have a smart part (sometimes called agenthood). However, since new Java actor frameworks are growing, I don't understand why FIPA is not coming into the field defining some kind of standards for such paradigm. It could be the best of both world, but as far as I know there is only a paper that tries to merge both.

Il database dimenticato e il database sottovalutato

Questo post nasce dopo aver seguito (e obiettato) alcuni talk al Java Day IV edizione.

Questo post puo' sembrare molto di parte, ma in realtà non lo è; essendo però io coinvolto nel panorama PostgreSQL non posso fare a meno di citare quest'ultimo.

Con amarezza al Java Day si è parlato molto dell'importanza dei dati, di tecniche di persistenza, di sistemi database, di RDBMS, ma i nomi che sono venuti fuori quali sono stati? Al solito: Oracle, DB2, MySQL. Sarà stata la presenza di Sun (e Oracle) e di IBM fra gli sponsor? Puo' essere, ma visto che si parla di OpenSource e soluzioni innovative, non vale la pena citare PostgreSQL? E se proprio non vi piace, potete almeno citare MariaDB (il fork di MySQL)? Possibile che dopo tutti gli sforzi della comunità PostgreSQL si debba ancora sentire parlare solo di Oracle o, quando si vuole abbondare nell'OpenSource, di MySQL?

Ma se fosse solo un problema di propaganda, questo mio post potrebbe fermarsi qui. E invece devo dire che, ancora con maggior amarezza, ho sentito cose allucinanti su queste bestie sconosciute che sono i DBMS. Ancora una volta si assiste al programmatore che pretende di saperne di piu' del DBA, e che vuole usare le proprie soluzioni per scavalcare quello che non capisce o non sa come usare al meglio. E io non sono da meno! Ma è meglio scendere in maggiori dettagli.

L'errore piu' grossolano è quello di cercare di giustificare la nascita di soluzioni e paradigmi innovativi dietro a problemi implementativi. Ad esempio ho sentito dire che un DMBS è scomodo perché se si deve aggiungere anche una sola colonna occorre riavviare il database (in piena notte, perché non lo si vuole certo fare nel momento di maggior carico!). E allora serve una soluzione che permetta al sistemista di dormire tranquillo e di non doversi alzare in piena notte per aggiungere una colonna. Per citare un famoso telefilm: "che cavolo stai dicendo Willis?". Non ho mai sentito che un database abbia bisogno di un riavvio in seguito ad una ALTER TABLE. Certo, l'alterazione della tabella potrebbe non essere immediato, a causa di concorrenza e locking, ma se non si puo' aspettare il tempo necessario alla fine delle transazioni significa che il DBMS è (molto) mission critical, e quindi si deve prevedere una qualche nottate in bianco. Altrimenti significa che il database implementa male l'ALTER TABLE, ma fino ad ora non ho ancora incontrato un database che rchiedesse un completo restart! Forse l'applicazione puo' richiedere un restart, ma questo è un altro problema (non possiamo accusare il DBMS di un meccanismo legato al class loading o al caching di un application server!).

Non è finita qui: il partizionamento verticale e orizzontale non puo' funzionare, perché non è affidabile se non in un'ottica master-slave. Ma quest'ultima a sua volta non risolve il problema delle notti insonni, poiché la caduta di un nodo richiede la riconfigurazione (sempre manuale) del sistema. Ma ancora una volta, si sta erroneamente accusando un problema implementativo (la riconfigurazione del sistema) trattandolo come problema di paradigma (la replicazione funziona).

Andando avanti si scopre che il partizionamento richiede anche maggior carico alle applicazioni: essendo le tabelle (e i relativi dati) separati fisicamente fra diversi database (o cluster), non è possibile fare i join, che quindi sono tutti a carico dell'applicazione. Ma e lo standard SQL MED? E la teoria che il database deve ritornare i dati consistenti cercando di ridurre il carico di lavoro dell'applicazione?

Conclude il tutto la classica affermazione che i dati dovrebbero essere processati localmente, e non dovrebbero quindi circolare nella rete. E cosa vuol dire questo? Facile: trigger! Certo, è vero, i trigger lavorano localmente ai dati, ma hanno uno scope limitato ad una operazione che li faccia scattare, mentre una tecnologia di codice mobile (come ad esempio gli adentimobili) potrebbe portare migliori risultati.

Ma come si risolvono tutti i problemi di cui sopra? Con il solito trucco dei programmatori: si inserisce un middleware intermedio che nasconda molti dettagli implementativi.

Not Only SQL.

E' sbagliato questo approccio? Assolutamente no, ma presentarlo e giustificarlo dietro a problemi che derivano soloda una pigrizia implementativa del vendor di database o dietro alle scarse conoscenze dei motori relazioni (alter table che richiede un restart...) è assolutamente ridicolo. Soprattutto percé si tenta di attaccare i DBMS in quanto una soluzione non adatta a tutti gli scenari, ma per farlo si usa un cappello comune e generico, che di conseguenza non puo' essere adatto per tutti gli scenari. In altre parole, io ritengo che un DBMS sia una soluzione piu' che valida per moltissimi scenari, che laddove non appare valida si debba valutare se le conoscenze sui DBMS (e il DBMS che si usa in quel contesto) siano corrette, e solo se queste non siano sufficienti (a risolvere i problemi di contesto) si debba passare ad una soluzione di piu' alto livello (un middleware ad esempio).

Per non parlare poi della base di installato di DBMS e della formazione di tutti i DBA. E se è vero che non ci si deve fossilizzare sulle conoscenze acquisite, è anche vero che è meglio implementare nuove feature nell'esistente che non creare qualcosa di completamente nuovo.

Cosa si evince da questa mia esperienza? La prima cosa è che PostgreSQL necessita di ancora molto lavoro di propaganda per essere accettato come soluzione comune ove serva un DBMS enterprise. La seconda è che non bisogna mai confondere i problemi e le limitazioni dell'implementazione con quelle che sono le problematiche e le necessità di paradigma. Sicuramente il paradigma di NoSQL è ottimoo, ma in questa occasione è stato presentato veramente male.

Java Day quarta edizione

Ho partecipato con interessa alla quarta edizione del Java Day a Roma. Anzitutto devo sottolineare come la convention sia stata organizzata in modo estremamente preciso da parte di tutto lo staff, ai quali vanno i miei complimenti. Il livello tecnico della conferenza è stato elevato, ma devo notare qualche piccolo problema su alcuni dettagli. Anzitutto la densità dell'evento, che prevedevaben sei track parallele distribuite in sole sei ore: questo ha richiesto la rinuncia a molti talk interessanti per ovvie ragioni di non ubiquità. In secondo luogo la lingua scelta per le slide di molti (quasi tutti) i relatori: l'inglese. Sebbene sia evidente che i programmatori e gli amministratori che si occupano di Java un po' di inglese lo devono masticare, presentare delle slide in inglese rappresenta un grave errore. Se infatti le slide risultano comprensibili ai piu', non ci si deve dimenticare che la conferenza vedeva la partecipazione di molti JUG italiani, e quindi una maggiore cura all'evangelizzazione e diffusione di Java a chi di inglese non sa molto (o non sa niente) non è fattore trascurabile. Queste giornate nazionali infatti devono servire anche come supporto e introduzione a chi non possiede sufficienti competenze tecniche e linguistiche per affrontare il viaggio nell'universo Java in modo autonomo. Infine, in quasi tutti i talk si è parlato molto di OpenSource ma quasi tutti gli esempi erano mirrati a soluzioni commerciali, Facebook e Twitter in primis. Reputo questo un grossolano errore: ci si sporca la bocca con termini che non corrispondono all'utilizzo che si fa poi dei sistemi e delle applicazioni.Sto sfociando nel fanatismo? Puo' essere, ma se si vuole parlare di OpenSource che lo si faccia fino in fondo, non solo per attirare attenzione e sfruttare l'OpenSource per fornire ulteriori servizi a sistemi commerciali e chiusi.
A parte questi piccoli problemi,importanti e non trascurabili, la conferenza è stata veramente molto interessante e mi ha dato molti spunti di riflessione e temi da approfondire.

Un treno nella direzione opposta

Non è passato molto dal mio ultimo post su Gigetto, il servizio ferroviario Modena-Sassuolo, e forse proprio per questo faccio ancora piu' caso ai problemi ad esso legati. Problemi che sono sempre gli stessi, o almeno si presentano sempre con cause simili e effetti identici.
E' nevicato, e come per la nevicata della Befana, il treno che questa mattina doveva portarmi in ufficio non è passato. Al suo posto, nello stesso momento, è invece passato il treno verso Modena. Ancora una volta un treno è stato sostituito dal suo gemello nella direzione opposta, e ancora una volta nessun avviso è stato esposto, né tramite cartelli cartacei né tramite pannelli luminosi. La corriera che doveva garantire il servizio non si è presentata nei 20 minuti di attesa.
A questo punto mi domando quale sia il reale scopo di questo servizio ferroviario. Considerando che in questi giorni è pericoloso girare in macchina, non dovrebbe forse questo servizio essere piu' affidabile che mai?

Viaggiare sul treno Modena-Sassuolo

Caro Gigetto,
sono un tuo fedele utente ormai da piu' di tre anni, e devo dire che apprezzo molto il poter viaggiare in treno. E' bello potersi assopire con il tuo leggero dondolio, è rilassante e costruttivo poter leggere mentre tu mi porti verso l'ufficio o mi riporti a casa, è bello poter fare due passi invece che sedersi in macchina ed è rilassante poter osservare il paesaggio che si muove attorno a me senza avere lo stress del traffico atuomobilistico.
Insomma, viaggiare in treno è proprio bello per me, anche per viaggi brevi come quello casa-ufficio.
Eppure, dopo l'ennesimo ritardo della odierna giornata di neve, devo rimproverarti.
Sono stanco.
Sono stanco di questi continui ritardi non segnalati, né con avvisi cartacei né tramite i display installati in ogni stazione.
Sono stanco di attendere al freddo e sotto la pioggia in stazioni che sembrano zone smilitarizzate, buie e prive di panchine.
Sono stanco di vedere macchinette distributrici di biglietti sempre accese che visualizzano la scritta "Fuori Servizio", un bello spreco di energia.
Sono stanco di dover fare le capriole per poter ricaricare l'abbonamento, visto che anche se i treni circolano fino a tarda serata ma le biglietterie alle 19.30 sono chiuse.
Sono stanco di salire su un treno sporco e puzzolente.
Sono stanco di vedere controllori che si rifiutano di aiutare i viaggiatori nel caricare e/o scaricare le proprie biciclette.
Sono stanco di essere trattato con sufficienza dai controllori quando ci si lamenta per i ritardi; è vero che non è colpa loro, ma come loro sono li per lavorare, noi siamo lì per cercare di andare a lavorare.
Sono stanco di fare segnalazioni per i vari problemi e non avere nessun feedback.
Sono stanco di pagare un biglietto caro per un servizio che in realtà il piu' delle volte è un disservizio.
Sono stanco di pagare un biglietto che il piu' delle volte è addebitato in modo errato a causa di zone e tariffe sbagliate.
Sono stanco.
Non ti tradirò, il piacere delle passeggiate, della lettura, dei pisolini è troppo grande. Ma ti confesso che è realmente difficile continuare a mascherare il fatto che gli svantaggi ormai superano i vantaggi.

PostgreSQL, MySQL, Oracle, Sun e qualche opinione in libertà

In questi giorni si fa un gran parlare del via libera della Commissione Europea a Oracle, che si appresta a fagocitare Sun, la quale a sua volta aveva già inghiottito MySQL AB. Questo per me, membro di ITPug, porta nuovamente a fare qualche considerazione sulle differenze tecniche fra PostgreSQL e MySQL. E non voglio parlare di differenze tecniche o tecnologiche, ma di differenze ideologiche.
MySQL è un prodotto figlio di una azienda, MySQL AB, che lo distribuisce in varie versioni, alcune libere e alcune commerciali.
PostgreSQL è figlio di una comunità.
Attorno a MySQL, prodotto di una azienda (e quindi commerciale, che lo si voglia o no) è nata una comunità.
Attorno alla comunità PostgreSQL sono nate delle aziende che hanno fatto del prodotto il loro business.
Insomma, due modelli di business nettamente differenti: il primo, quello di MySQL, nato dall'alto di una azienda e donato ad una comunità che potesse gestirlo (in parte); il secondo, quello di PostgreSQL, nato dal basso di una comunità e usato da aziende a scopi commerciali. Ma se alla fine si giunge sempre a prodotti commerciali, che differenze c'è? Il controllo è la differenza! In PostgreSQL le aziende "sfruttano" (in senso buono) il lavoro della comunità, lo possono estendere, lo possono rendere proprietario, ma non possono forzare tutta la comunità a seguire le loro necessità; in MySQL, la comunità è costretta a seguire le necessità di un'azienda. Certo, la comunità ha sempre un'arma molto potente, che è il "forking" (creazione di un nuovo ramo di sviluppo), ma creare un fork di un progetto non è cosa semplice: occorre trovare gli sviluppatori, sincronizzarli, definire i nuovi obbiettivi, e, per dirla in breve, ricominciare tutta una serie di attività che si erano consolidate nel progetto precedente. Quindi mentre la comunità PostgreSQL continuerà a sviluppare il sistema avendo in mente il "bene" dell'intero progetto (e dei suoi utenti), un prodotto ormai commerciale come MySQL verrà sviluppato prevalentemente con lo scopo di conquistare posizioni di mercato.

Ma le differenze non si fermano solo ai modelli di business, ma alla cultura dietro ai due database. Mentre PostgreSQL nasce come sistema per DBA, e quindi richiede conoscenze tecniche approfondite per la sua corretta gestione, MySQL nasce come supporto per gli sviluppatori (non DBA) che devono testare le loro applicazioni in ambito database senza dover perdere tempo in tuning, configurazione, schemi e indici. Senza nulla togliere a MySQL, che si è evoluto fino a diventare un ottimo database, va sottolineato che esso rimane comunque un database con scopi piu' limitati rispetto a PostgreSQL. Ed ecco che con Oracle che controlla anche la fascia di mercato di MySQL gli sviluppatori saranno naturalmente portati a scrivere applicazioni Oracle-compatibili,e da lì il salto verso tale piattaforma sarà solo questione di tempo.

E infine mi appare ridicolo il messaggio di Monty per salvare MySQL dall'acquisizione di Oracle. A cosa pensava Monty quando ha ceduto MySQL a Sun? Forse ai $$ incassati piu' che alla sopravvivenza di MySQL! E se adesso Monty vuole che MySQL rimanda Open Source perché non si è affidato ad una singola licenza copyleft invece dello schema a due licenze? E perché adesso ci si preoccupa dei rapporti con la comunità, lo sviluppo OpenSource e il fatto che il codice resti disponibile in licenza OpenSource (ma InnoDB non è di Oracle?) ma gli stessi problemi non sono emersi con l'acquisizione di Sun? La mia maliziosa e personale interpretazione è che Sun poteva essere un trampolino di lancio per MySQL, essendo interessata ad usare tale database come suo principale livello in uno stack AMP, Ora Oracle invece, che ha già a disposizione un valido prodotto database, potrebbe voler polverizzare MySQL in favore del suo prodotto. E questo preoccupa il creatore di MySQL, che ha ben capito che un fork è al momento una soluzione di ripiego.

Infine una nota complementare, ma per me abbastanza importante: MySQL viene rilasciato anche con licenza GPLv2, mentre PostgreSQL con licenza BSD. Indipendentemente dal giudizio personale su una o l'altra licenza, la FSF spinge assolutamente in direzione di licenze CopyLeft (quindi GPL) e di conseguenza la FSF ritiene che per raggiungere il proprio scopo MySQL abbia licenza migliore di quella di PostgreSQL. Questo si riflette in un fattore pubblicitario a favore di MySQL. Perché è importante questo? Perché i sostenitori di MySQL hanno smosso anche la FSF (e Stallman in persona) per cercare di evitare che Oracle assorba Sun e quindi possa avere diritto di vita e di morte su MySQL.

Scrolling automatico di una immagine SWT

E' stata abbastanza dura riuscire a creare una view di Eclipse che potesse fare lo scrolling di una immagine in automatico. Mentre in Swing esiste il poliedrico componente ScrollPane, capace di fare scrolling automatico su praticamente ogni componente (ivi incluse le immagini), nel caso di SWT l'affare si complica.
Anzitutto occorre creare un canvas capace di visualizzare l'immagine, e quindi con associato un paint listener che reagisca agli eventi di rivisualizzazione e disegni l'immagine al suo interno. Attenzione: l'immagine deve essere disegnata sempre nello stesso punto (ad esempio alle coordinate 0,0) poiché non è il canvas a muovere l'immagine ma lo scrolled composite che conterrà il canvas. Terminata la costruzione del canvas, si procede al wrapping dello stesso in uno ScrolledComposite che si preoccuperà di muovere il canvas contenuto. Purtroppo c'è un po' di lavoro in piu' da fare: lo scrolled composite deve avere esplicitamente settato il suo contenuto (il canvas).
Da un punto di vista di codice, questo si traduce nel seguente frammento di inizializzazione della vista Eclipse:

  public void createPartControl(Composite parent) {
  
 // create a scrolling composite
 ScrolledComposite scroller = new ScrolledComposite(parent, SWT.V_SCROLL | SWT.H_SCROLL );
 
 // now create a canvas for this view
 this.canvas = new Canvas( scroller, SWT.NONE );
 scroller.setContent( this.canvas );
 
 
 // this canvas must show the image when loaded
 
 this.canvas.addPaintListener( new PaintListener(){


     @Override
     public void paintControl(PaintEvent event) {
  if( image != null )
      event.gc.drawImage(image, 0, 0 );
     }
    
 });
 

       ...
   }

Wrap automatico di un file di testo

Il comando fold è molto utile per fare il line-wrap automatico di un file di testo specificato come argomento. Il suo utilizzo è molto semplice: supponendo di voler fare il wrap dopo 60 caratteri e solo in presenza di un carattere spazio si ha che

fold -sw 60 file.txt

produce in uscita il file corretto. Il flag -w abilita il wrap, mentre il flag -s abilita l'interruzione di linea solo in presenza di uno spazio.

Gnome Network Manager, chiavetta internet 3 e /etc/resolv.conf

L'applet network manager di Gnome su una Ubuntu Netbook Remix gestisce egregiamente le chiavette Internet della 3 (modem Huawei E1550), ma c'è un problema per la risoluzione degli host: una volta avviata la connessione il file /etc(resolv.conf risulta vuoto e quindi nessun DNS viene configurato nel sistema.
Una possibile soluzione al problema è quella di impostare i DNS da usarsi nel file /etc/resolv.conf e cambiare gli attributi del file in modo che nessun programma, ivi incluso Network Manager, possa sovrascriverlo:

chattr +i /etc/resolv.conf

La mia (dis)avventura con OpenSolaris 2009.11

Le premesse
Utilizzo Linux da almeno 10 anni, mi trovo molto bene con
un sistema così flessibile e configurabile. Grazie a Linux
e al suo ecosistema ho potuto apprezzare l'OpenSource e
sposare questo modello di sviluppo e questa filosofia di
pensiero. Inizialmente usavo sistemi rpm-based, poi una
volta scoperto il package manager di Debian mi sono
convertito a questi tipi di distribuxzione. Ritengo infatti
che passare ore a configurare e compilare software serva
per sistemi mission-critical, non per farmi fare altra
pratica e passare notti sveglio al computer.

Sono un fan fedele del KDE, ho stretto i denti con quel
bagno di sangue che fu il passaggio alla versione 4.0, e
sono contento di aver visto tutte le versioni fin dalla
prima. Non apprezzo il KDE solo per il suo aspetto grafico
(che oggettivamente puo' essere considerato di gran lunga
superiore ai suoi rivali), ho studiato le librerie Qt sulle
quali è costruito, le ho confrontate con le GTK+ alla base
delle librerie e del desktop Gnome e ritengo il binomio
Qt/KDE molto piu' elegante di quello GTK+/Gnome. La mia
applicazione desktop principale è KMail, il miglior client
di posta che abbia mai visto (e ne ho provati tanti...).

Sviluppo applicazioni Java (e non solo) utilizzando l'IDE
Eclipse, che ritengo il miglior IDE disponibile per Java.
Ho iniziato ad usarlo all'epoca della versione 2, dopo aver
visto dal vivo una dimostrazione ad una conferenza in
Irlanda (all'epoca usavo il pachidermico Netbeans, che
comunque era piu' smilzo di Forte For Java!). L'unico
svantaggio che trovo in Eclipse è che la versione Linux
utilizza il binding con GTK+, quindi il suo utilizzo in KDE
non risulta pienamente integrato e performante. Da notare
che, siccome sviluppo anche applicazioni RCP, sono legato a
Eclipse come piattaforma.

Il mio editor preferito è Emacs (anch'esso con binding
sulle GTK+ - non poteva essere altrimenti essendo l'editor
di Stallman!) anche se la maggior parte delle volte
direttamente a terminale (quindi senza mouse).

Quasi tutte le cose che faccio le svolgo attraverso la
Konsole, e spesso ho piu' di 5 tab attivi
contemporaneamente.

Utilizzo Kopete per l'instant messaging, e lo trovo un
programma molto utile e ben strutturato, anche se devo
ammettere mi sembra meno polimorfico del suo antagonista
Pidgin.

Il mio browser preferito è Firefox, dopo aver usato
infatti a lungo Konqueror ho deciso di usare il prodotto di
Mozilla poiché consente l'installazione di molti plugin e
addon per il debug e l'analisi delle applicazioni Web.

Utilizzo git come SCM anche per i miei documenti personali
(almeno per quelli per i quali abbia senso mantenere le
versioni). Ovviamente per molti "progetti" non ha senso
usare uno strumento potente come git, ma sono un ingegnere
pragmatico e tendo ad usare i migliori strumenti
disponibili, o meglio quelli che ritengo migliori, per
capirne a fondo la mentalità e le potenzialità in ogni
situazione.

Proprio per questa mia curiosità e voglia di usare sempre
gli strumenti migliori, qualche mese fa mi interstadisco a
studiare OpenSolaris. Seguo lo sviluppo del sistema dal
2006 (piu' o meno quando venne reso open il cuore di
Solaris) e conosco Solaris dai tempi dell'università
(amministravo alcune workstation sun4u). Quindi non ero
digiuno del sistema Solaris/OpenSolaris quando ho deciso di
riprendere in mano il sistema. E finalmente mi decido a
provarlo sul mio portatile, un Acer Aspire 6935, poiché
l'unico modo per imparare veramente un sistema, secondo me,
è quello di lavorarci ogni giorno. E qui comincia la mia
avventura.

Installazione e utilizzo di OpenSolaris
La mia prima idea è quella di installare OpenSolaris a
fianco del mio sistema Linux, quindi in triple boot. Per
farlo libero una delle tante partizioni presenti sul mio
disco e inizio il proceesso di installazione di
OpenSolaris. Stranamente la finestra di partizionamento non
riconosce nessuna partizione estesa (e quella liberata era
ahimé estesa). Dopo un po' di ricerca sul Web ho scoperto
che OpenSolaris non supporta ancora le partizioni estese, e
quindi non posso procedere all'installazione sul mio
computer. A questo punto l'unica soluzione è quella di
rimuovere Linux, ma ancora non mi sento pronto, quindi
decido di installare OpenSolaris su una macchina virtuale.

Creo quindi una macchina VirtualBox sulla quale inizio a
fare esperimenti. Grazie alla bibbia di OpenSolaris
sperimento il fantastico ZFS, le zone e IPS. Aggiorno il
sistema, uso RBAC, SVC e sperimento la stabilità di
OpenSolaris. Il sistema mi piace, così decido di provare a
creare un ambiente simile al mio Linux per essere sicuro
che tutto possa funzionare in una installazione sul
bare-metal.
Inizio dal KDE: OpenSolaris viene distribuito con Gnome, e
KDE 4 non è aggiornato alle ultime versioni. Con non poca
fatica riesco ad installare KDE 4.3.2 quando sul mio Linux
sto usando un KDE 4.3.4. A questo punto, con KDE al suo
posto, posso migrare posta, instant messaging e i profili
di Konsole. Ma ora viene la prima nota dolente: uno dei
compilatori che uso al lavoro non è disponibile per Unix
ma solo per Linux. La mia prima idea è quella di usare una
branded-zone, ma alla fine non mi interessa installare un
Linux virtualizzato in branded-zone, mi va bene installarlo
anche come VirtualBox. In sostanza, posso aggirare
l'ostacolo del compilatore mediante la virtualizzazione;
non sarà comodo come accedere direttamente dal sistema
host, ma almeno funzionerà. Dopotutto si deve essere
disposti a fare qualche sacrificio per usare il meglio che
ci sia, no?
Per gli altri programmi non sembrano esserci problemi:
installo Eclipse dai repository IPS e sembra tutto a posto.
Ahimé non lo testo appieno, cosa che mi costerà in futuro.
Insomma, mi sento pronto per installare OpenSolaris sul
bare-metal.

Ma il bare-metal non è la macchina virtuale!
Dedico una partizione da 170GB a OpenSolaris e avvio il
processo di installazione, che stranamente si blocca al 70%
e si congela. Forse un problema del CD-Rom, comunque non si
ripeterà piu' nelle successive installazioni.

Finalmente il momento del primo avvio e la prima amara
sorpresa: mentre la scheda di rete wireless funziona
benissimo, la scheda ethernet (Atheros) non viene
riconosciuta. Dopo una ricerca sul Web scopro che il driver
della mia scheda di rete è contenuto nel pacchetto
SUNWatge, ma l'installazione tramite IPS non funziona a
causa del diverso snv (il 2009.11 ha snv 111, mentre il
pacchetto in questione richiedeva snv 130). Devo quindi
prima aggiornare il sistema da snv_111 a snv_130, cosa che
richiede il download di circa 890 MB di software (tramite
scheda wireless!). Al riavvio del sistema un'alta amara
sorpresa: GDM si lamenta circa il file /Xsession e la
finestra di login sembra avere problemi a visualizzare
correttamente sfondo e menu' delle opzioni. Non solo, una
volta fatto il login lo schermo rimane completamente
bianco! Dopo un po' scopro che il sistema non è congelato,
sta funzionando (ALT+TAB mi mostra il movimento fra
finestre tutte bianche senza farmi vedere i contenuti), e
da una ricerca sul Web scopro che l'aggiornamento snv_130
ha effettivamente qualche problema con le schede grafiche
NVidia che puo' produrre questo strano effetto se Compiz è
abilitato. La soluzione consiste nel fare il login da una
sessione Failsafe e invocare il programma di "pulizia"
gnome-cleanup per rimuovere le preferenze del desktop e
disabilitare quindi Compiz. In questo modo, a parte il
problema a GDM, posso fare il login correttamente anche se
ora il desktop Gnome risulta "piatto" e privo di effetti.

Prima di procedere all'installazione del software desktop
(KDE prima di tutto) decido di installare Eclipse. Il
repository IPS propone ancora Eclipse 3.4.2 anziché la
nuova serie 3.5, ma questo non è per me un grosso
problema. Però in Eclipse devo installare diverse librerie
e plugin (AspectJ, EGit, le librerie per lo sviluppo RCP,
...) e quindi inizio la procedura di installazione del
nuovo software dall'interno dell'IDE. Qualcosa però non
va: dopo le prime dialog di selezione del software, Eclipse
sembra bloccato. Pur premendo il classico pulsante "Next"
della dialog corrente, che sembra rispondere all'input,
l'IDE non fa nulla. Di fatto sembra che la pressione del
pulsante faccia perdere il focus alla selezione corrente.
Provo e riprovo ma non riesco ad installare i plugin che mi
servono.

A questo punto mi trovo ad un punto morto: OpenSolaris ha
dei problemi (Eclipse, GDM, la scheda grafica) e io sono
senza il mio ambiente desktop e, cosa piu' importante, i
miei dati personali (ad esempio la posta). Nonostante fossi
disposto ad accettare l'uso di un KDE leggermente piu'
arretrato rispetto agli ultimi rilasci (purché stabili),
nonostante fossi anche disposto a valutare il passaggio a
Gnome (bisogna pur provare tutto, no?), nonostante potessi
soprassedere sull'assenza delle ultime versioni di Eclipse
(anche se la 3.5 esiste per Solaris, ma non è compatibile
con OpenSolaris), mi trovo con le mani legate. Insomma,
già puo' essere difficile il passaggio ad un sistema
architetturalmente differente, ma farlo senza nemmeno le
proprie applicazioni potrebbe essere troppo!

Devo ripiegare e reinstallare Linux, nel quale ovviamente
riesco a ricaricare velocemente i miei dati e le mie
applicazioni. Insomma, torno al punto di partenza.

Ma mi sono tenuto una partizione primaria per tornare a
sperimentare con OpenSolaris con piu' calma e direttamente
sul bare-metal.
Credo fermamente che OpenSolaris sia un sistema innovativo
e degno di nota, e che sia anche un'ottima dimostrazione di
cosa puo' fare l'OpenSource. 

Content Assistant vuoto in Eclipse 3.5

Utilizzo Eclipse come IDE ormai da diversi anni, e mi trovo molto bene. Una delle caratteristiche che ho sempre apprezzato maggiormente negli IDE (e che ho sempre cercato di insegnare anche ai miei studenti) è la loro capacità di eseguire reflection sul codice e fornire suggerimenti appropriati al contesto.
In Eclipse questo si traduce nel Content Assistant, il menu' a tendina che si attiva con CTRL + space o dopo alcuni millisecondi dalla digitazione di un carattere '.'.
A volte capita che l'installazione di un qualche plugin vada a modificare le impostazioni del content assistant, facendo si che il componente funzioni ma non sia grado di offrire suggerimenti (in sostanza si ottiene un menu' vuoto). Tipicamente questo succede quando vengono disabilitati i suggerimenti per i tipi Java e Java in generale. Per riabilitare il content assistant è sufficiente andare nelle preferenze di Eclipse, nella sezione Java, sottosezione Editor e sottosezione Content Assistant; qui si prende la sottosezione Advanced e si riabilitano i suggerimenti per le categorie Java.

Errore di chiave duplicata su large object

PostgreSQL memorizza i large objects (bytea) in una tabella pg_largeobject, che come si intuisce dal suffisso appartiene al catalogo di sistema. Come riportato dal manuale, la tabella memorizza l'oid dell'oggetto (ottenuto alla sua creazione) e i dati effettivi dell'oggetto.
Potrebbe capitare, a seguito di diversi restore dello stesso database, che PostgreSQL produca l'errore

ERROR:  duplicate key violates unique constraint "pg_largeobject_loid_pn_index"

che indica che si sta cercando di inserire due volte lo stesso large object. Questo perché la tabella che memorizza i dati (e l'oid dell'oggetto) non appartiene al singolo database ma all'intero sistema (altrimenti non dovrebbe mai capitare una duplicate key in seguito ad un drop/create del database).
In questa situazione è necessario svuotare la tabella dei large object (completamente o parzialmente) con una istruzione di DELETE.

psql: fermarsi al primo errore

Il terminale interattivo di PostgreSQL, psql, consente di eseguire un file di comandi SQL in sequenza con il comando speciale \i nomeFile. Tuttavia se tale file contiene degli errori psql continuerà a processare il file (anche se i comandi non verranno applicati a causa del fallimento della transazione corrente). Come risultato si vedranno passare sullo schermo una serie di messaggi di errore causati dal primo errore rilevato nel file. E' possibile dire a psql di fermarsi al primo errore rilevato nel file mediante il comando speciale

\set ON_ERROR_STOP

da lanciare prima dell'esecuzione del file comandi tramite \i.

Query per eliminare gli oggetti di un utente

Usando il catalogo di sistema è possibile ottenere l'elenco degli oggetti di un determinato utente nel sistema (e nello schema), e da queste è possibile costruire le query da eseguire (una ad una) per eliminare tali oggetti:

SELECT 'DROP ' || case when relkind ='r' THEN 'TABLE' WHEN relkind='S' THEN 'SEQUENCE' WHEN relkind='v' THEN 'VIEW' END || ' ' || relname || ' CASCADE;' FROM pg_class JOIN pg_authid ON pg_class.relowner = pg_authid.oid WHERE rolname='luca';

La query riportata qui sopra elenca tutti gli oggetti di proprietà dell'utente luca e provvede a creare automaticamente delle query del tipo DROP per i vari elementi. Da notare che viene automaticamente riconosciuto, tramite l'attritubo pg_class.relkind il tipo di un oggetto, e quindi vengono generate query DROP TABLE come DROP SEQUENCE e DROP VIEW. Ovviamente è possibile estendere la query per ottenere l'eliminazione di altri tipi di oggetti.

E' sufficiente redirigere l'output di questa query verso un file di testo per poi procedere all'eliminazione di tutte le tabelle/oggetti selezionati.