Nuove community dopo l'acquisizione da parte di Oracle di Sun

E c'è ancora chi non si preoccupa della politica del software! Mi fanno ridere quei guru (presunti) dei database che mesi fa scrivevano di non avere alcun interesse a seguire la faccenda MySQL/PostgreSQL/Oracle, mostrando una pesante incompetenza nel non voler comprendere come il software oggi giorno non sia solo una manciata di file sorgenti ma un vero e proprio sistema politico.

ad ogni modo, vista la reluttanza di Oracle nel fornire uno straccio di supporto alle comunità OpenSource che alla fine le hanno donato, tramite Sun, ottimi prodotti, molte community si stanno organizzando, ri-organizzando e preparando ad uno sviluppo "parallelo" se non proprio a dei veri e propri fork dei progetti Sun/Oracle.

Due in particolare vanno citate:

• OpenIndiana che promette di portare avanti (e a termine) lo sviluppo di OpenSolaris. OpenIndiana a sua volta è figlio di un progetto nato ad Agosto, quando la OpenSolaris Governing Board non ricevette alcuna risposta da Oracle, denominato Illumos. E OpenSolaris (il sistema operativo) che fine ha fatto? Il sistema diventerà il nuovo Solaris 11, e dal sito web ufficiale è sparito il comodo link per scaricare la developer build, ora piu' nascosto, mentre il download ufficiale punta alla versione 2009.06. Di fatto ogni tentativo per tenere in vita un colloquio fra la community di OpenSolaris e Oracle è stato vano:

All of Oracle’s efforts on binary distributions of Solaris technology
will be focused on Solaris 11. We will not release any other binary
distributions, such as nightly or bi-weekly builds of Solaris
binaries, or an OpenSolaris 2010.05 or later distribution. We will
determine a simple, cost-effective means of getting enterprise users
of prior OpenSolaris binary releases to migrate to S11 Express.

• LibreOffice è una comunità nata attorno al progetto OpenOffice con il chiaro intento di produrre una suite per ufficio libera, come lo è stata OpenOffice, senza però nessuna azienda che ne governi il ciclo di vita.

Quindi dopo la fuga dei cervelli da Oracle, alcuni fra i progetti piu' importanti e visibili ereditati da Sun iniziano a vivere di vita propria per non dover rischiare di vederli morire per una strategia commerciale. 

Oggi però, come sviluppatore Java, mi da da pensare il fatto che IBM voglia unirsi a Oracle per lo sviluppo di OpenJDK. Dentro di me penso all'eterna battaglia IBM vs Sun per il predominio di Java, battaglia che mi ha sempre fatto pendere dalla parte di IBM per gli ottimi prodotti realizzati (Eclipse, Jikes - compilatore e virtual machine, SWT), e penso che IBM potrebbe tranquillamente stare sulle proprie gambe nella battaglia per Java. Ma forse non è IBM ad avere paura, è Oracle (si veda la battaglia legale contro Google). E allora Oracle, spaventata, cosa fa? Cerca di accaparrarsi le simpatie degli sviluppatori che si fidano di IBM. E IBM accetta perché ha tutto l'interesse nel diventare partner del vendor Java. Almeno, questa potrebbe essere una interpretazione.

PGDay 2010

I lavori per il PGDay 2010, che si svolgerà a Roma prima della fine dell'anno, esattamente il 10 Dicembre, stanno procedendo a pieno ritmo. Sicuramente questa edizione sarà un'ulteriore successo italiano di PostgreSQL.

Per maggiori informazioni si consulti il sito web ufficiale: www.pgday.ithttp://www.pgday.it

SWT Widget Disposed & asyncExec

Quando si eseguono operazioni time-consuming in una applicazione SWT occorre che queste siano eseguite fuori dal thread grafico, pena il freeze dell'interfaccia grafica. SWT mette a disposizione due metodi per l'esecuzione di task lunghi:

• i job, simili a dei thread Java contengono il codice da eseguire secondo una politica di schedulazione (anche immediata)
• gli sync/asyncExec, ossia l'esecuzione di un Runnable appena il thread grafico (UI Thread) può

I due approcci, seppur simili,hanno un utilizzo piuttosto differente: i job vengono usati per tutto quello che è prevalentemente non-UI e che non aggiornerà l'interfaccia grafica, mentre gli xxxExec sono per quei processi che richiedono un aggiornamento costante dell'interfaccia grafica, ad esempio per riportare il progresso di una operazione.

Il problema degli asyncExec è che potrebbero venire schedulati per l'esecuzione dopo il disposal di un widget, cosa che si verifica ad esempio quando l'applicazione viene chiusa. In questo caso viene generata una eccezione SWTException che indica appunto che era rimasto in coda un qualche Runnable per l'esecuzione ma che il thread UI non ha fatto in tempo ad eseguirlo prima della chiusura del widget:

 
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed) 

Per ovviare al problema, ogni asyncExec deve testare la validità del widget sopra il quale opera prima di effettuare le modifiche. Si noti che non basta controllare la validità del widget prima della schedulazione del Runnable, poiché questo problema si verifica in base alla capacità del thread UI di schedulare i Runnable e questa non è nota a priori. I Control dispongono tutti di un metodo isDisposed(), che non è però esposto in un Viewer, perciò se si opera con questi ultimi occorre prima recuperare il Control interno (getControl()) e testare quest'ultimo.

Ottenere informazioni su generics a run-time

Un problema con il quale mi sono scontrato spesso è quello di rilevare i tipi parametrici usati in una dichiarazione generics a run-time. Senza spendere troppe parole, basti sapere che Java nel suo package reflect, prevede un super-tipo Type che corrisponde a tutti i tipi possibili Java, sia oggetti che primitivi. Una sottoclasse particolare di un tipo è un tipo parametrico, identificato da ParameterizedType. Tale tipo contiene la definizione di un tipo generico, con tanto di identificatore simbolico e classe usata per definire il tipo. Tuttavia la reflection normale di Java non è sufficiente per ottenere la definizione parametrica a run-time: occorre passare attraverso la definizione esplicita di Class con informazioni generiche. Ecco quindi che, da un qualunque tipo, è possibile risalire al primo parametro generics usato nella sua definizione con il seguente semplice metodo:

public final Class getModelTypeOfThisDAO() {
   
        // get the superclass definition as a generic one
        ParameterizedType genericSuperClass = (ParameterizedType) this.getClass().getGenericSuperclass();
       
        // now get the first argument of the class
        return (Class) genericSuperClass.getActualTypeArguments()[0];
}

Kubuntu 10.04 & Network Management Disabled

Una cosa piuttosto noiosa del network manager di KDE (KNetworkManager) è l'incapacità di ripristinare la funzionalità delle schede di rete, soprattutto quelle wireless, qualora il sistema venga sospeso o vada in stand-by.
Quando il network manager continua, insistentemente, a riportare che il network management è disabilitato, la soluzione consiste nel:

- editare il file /var/lib/NetworkManager/NetworkManager.state impostando lo stato del networking da disabilitato ad abilitato (NetworkingEnabled=true)
- riavviare il servizio di network management con service network-manager restart

Gnome 3, Kde 4, libertà e l'inversione di progetto

Ho usato KDE fin dalla prima versione, e contemporaneamente Gnome da quello che fu' la prima versione stabile (October Gnome). Ho seguito attentamente l'evoluzione di entrambi gli ambienti, preferendo sempre KDE poiché piu' funzionale e completo. Ho studiato le librerie GTK+ (fondamento di Gnome) e quelle Qt (fondamento di KDE). Penso quindi di conoscere bene i due DE (Desktop Environment) per poterne fare una ulteriore analisi.

Una delle principali accuse rivolte dalla comunità Gnome a quella KDE con l'uscita del ramo 4.x è stata la rivoluzione operata da quest'ultimo: basti pensare che perfino Linus Torvalds, estimatore del desktop del drago, lo ha abbandonato in favore di Gnome perché KDE 4 ha rivoluzionato, forse troppo rapidamente, il modo di fare desktop. Non esiste piu' infatti un concetto di desktop statico, con un pannello, delle icone, e dei menu', ma un sistema di applet (dette Plasmoids) che possono contenersi l'un l'altra. Allora l'applet che indica il livello di carica della batteria può essere messa sul desktop, o sul pannello, o dentro ad un menu', poiché la struttura è "circolare". Ma questo significa anche che il desktop non è piu' un semplice contenitore di cartelle e file (icone), ma una vera piattaforma operativa. Gnome di contro si presenta ancora in versione "semplice", e sicuramente piu' vicina all'utilizzo classico di utenti tradizionali. Ma Gnome 3 cambierà tutto: ho provato la shell su un pc dedicato e devo dire che la rivoluzione sarà pesante anche per gli utenti Gnome. In particolare non capisco perché, per aprire un menù, l'utente sia costretto a vedere ridimensionato l'intero desktop.

Caduta quindi la tesi rivoluzionaria di KDE, vorrei analizzare i due progetti da altri punti di vista. Anzitutto dal nome: Gnome significa GNU Network Object Model Environment, ossia sistema ad oggetti trasparenti alla rete e, per ammissione del suo fondatore Miguel De Icaza, un sistema con idee prese in prestito dal COM di Microsoft. KDE invece significa Kool Desktop, ed è un ovvio gioco di parole sul CDE. Ad oggi KDE è molto piu' network oriented di Gnome, visto che i plasmoid possono essere condivisi sulla rete da un computer all'altro, il desktop rende realmente ogni operazione trasparente alla rete. Gnome invece si è fossilizzato sul classico desktop, sicuramente funzionale, ma non così network oriented come si era ripromesso. Si è quindi arrivati ad una inversione di progetto: KDE è nato per fornire un desktop efficiente ed efficace, ed oggi è network oriented, Gnome invece era piu' ambizioso e oggi si propone come desktop "statico".

Ma c'è anche un altro punto fondamentale: la libertà. Gnome nasce su volontà della GNU, proprio per contrastare i problemi di licenza delle Qt, e quindi si propone di fatto come desktop libero. Però la versione 1.x di Gnome non piace molto, o meglio viene sorpassata da KDE in tutto e per tutto. Si deve aspettare l'intervento di grossi vendor come Sun, IBM, RedHat, che investendo sul desktop della scimmia creano quella usabilità di Gnome 2. KDE invece non ha aziende alle sue spalle, solo la comunità di sviluppatori. Quindi, paradossalmente, KDE è piu' libero di Gnome, visto che il primo si evolve come gli sviluppatori vogliono, mentre il secondo come vogliono i vendor. Per meglio comprendere questa cosa si pensi ad Ubuntu e Kubuntu: il primo fornisce codice indietro a Gnome, ma crea personalizzazioni per attirare piu' utenti (ad esempio il recente visualizzatore/controllore audio integrato nel menù del volume), il secondo fornisce una pura installazione KDE senza personalizzazioni. Ancora si pensi ad OpenSolaris (e derivati) che hanno implementato plugin appositi (ad esempio TimeSlider per Nautilus) solo per la versione Gnome, mentre KDE non giova nemmeno del supporto della piattaforma.

Infine si pensi all'innovazione tecnologica di KDE: chi ammira i prodotti Apple dovrebbe ricordarsi che WebKit, la piattaforma Web di KDE, ha dato vita a Safari e alla dashboard, così come i plasmoidi sono eseguibili nativamente su KDE. In altre parole, KDE e OSX hanno molto in comune, grazie agli sforzi del primo.

Quindi quali sono i vantaggi e gli svantaggi nell'uso dei due DE? I vantaggi nell'uso di Gnome sono la semplicità e il supporto dei vendor, che garantisce una buona interoperabilità hardware/software. Gli svantaggi sono la scarsa personalizzazione (se raffrontata a KDE) e la scarsa tecnologia. I vantaggi nell'uso del KDE sono la grande innovazione tecnologica, la grande possibilità di personalizzazione e l'interoperabilità con altre piattaforme. Gli svantaggi sono il suo sviluppo, troppo legato agli sviluppatori che quindi creano tool complessi per utenti esperti (in linea con la filosofia Unix) e non si curano troppo degli utenti alle prime armi.

E come nota conclusiva segnalo che il passaggio alle GTK+ 3 non è stato preso attentamente in considerazione da IBM (che sicuramente recupererà), mentre so che è in corso un porting delle SWT su Qt.