Rust, Gnome & friends

C'è un certo momentum attorno al linguaggio di programmazione Rust.
Premetto che non ho mai utilizzato Rust nemmeno per il classico "Hello World", tuttavia ho provato a leggere la documentazione
e devo essere sincero: mi pare un linguaggio abbastanza complesso e pieno di keyword e di trabocchetti che non sono propri
di un linguaggio che si propone come un C migliorato.

Ad ogni modo pare che il team Gnome voglia passare a Rust per l'implementazione delle librerie e della infrastruttura ad oggetti
del famoso desktop. O meglio, si vuole pluggare componenti Rust nel sistema ad oggetti GTK+. Conosco GTK+, anche se sono molti
anni che non lo "utilizzo" da vicino: l'idea è bella ed elegante e si basa sulla costruzione di un sistema OOP puramente in C.
E riesce bene nello scopo, a patto di ricordarsi alcune regole boilerplate per la definizione dei nuovi tipi (classi).
Evidentemente, proponendosi Rust come un super-C ad oggetti, l'idea del team Gnome è quella di usare Rust per ridurre il codice
boilerplate pur mantenendo la dorsale GTK+ (per ovvia retrocompatibilità).

Francamente non mi pare che Gnome negli ultimi anni si sia mosso nelle giuste direzioni, e questa di Rust mi sembra l'ennesima
"cantonata" dettata quasi piu' dalla moda che non da problematiche tecnologiche. GTK+ è un sistema solido, testato, affermato
e modificarlo adesso creando una sorta di super-binding per Rust rischia di confondere i programmatori e creare piu' incompatibilità
rispetto ai problemi risolti. Sono sicuro che Gnome ha valutato molto bene vantaggi e svantaggi di questo approccio, e la mia resta
una pura riflessione personale, ma onestamente trovo abbastanza complesso e poco elegante il linguaggio scelto.

Da ultimo, per una visione piu' simile alla mia, si legga questo interessante articolo sull'adozione di nuovi linguaggi (fra i quali Rust).

Oracle SQL Developer: crash all'avvio

Ahimé mi sono trovato, non so per quale motivo, a non avere piu' funzionante il mio Oracle SQL Developer 4.15 su una macchina ubuntu 16.10.

Il problema era un crash, spesso immediato, casuale dell'applicativo, con messaggi e frame di errore ogni volta differenti:

Oracle SQL Developer
Copyright (c) 1997, 2015, Oracle and/or its affiliates. All rights reserved.



LOAD TIME : 286#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xe76ab451, pid=23989, tid=0xa82ffb40
#
# JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build 1.8.0_111-b14)
# Java VM: Java HotSpot(TM) Server VM (25.111-b14 mixed mode linux-x86 )
# Problematic frame:
# J 6797 C2 oracle.dbtools.util.Array.merge([I[I)[I (225 bytes) @ 0xe76ab451 [0xe76ab2c0+0x191]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/luca/Downloads/sqldeveloper/sqldeveloper/bin/hs_err_pid23989.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
/home/luca/Downloads/sqldeveloper/sqldeveloper/bin/../../ide/bin/launcher.sh: line 1286: 23989 Aborted (core dumped) ${JAVA} "${APP_VM_OPTS[@]}" ${APP_ENV_VARS} -classpath ${APP_CLASSPATH} ${APP_MAIN_CLASS} "${APP_APP_OPTS[@]}"


o dei blocchi all'avvio:

LOAD TIME : 259Uncaught error fetching image:
java.lang.NullPointerException
at org.netbeans.modules.netbinox.JarBundleFile$CachingEntry.getInputStream(JarBundleFile.java:342)
at org.eclipse.osgi.framework.internal.core.BundleURLConnection.connect(BundleURLConnection.java:53)
at org.eclipse.osgi.framework.internal.core.BundleURLConnection.getInputStream(BundleURLConnection.java:99)
at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:127)
at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:263)
at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:205)
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)

Preso dalla disperazione ho cercato di ovviare con la perspective Database di Eclipse, ma questa è a mio avviso molto insoddisfacente per l'interazione con il database (mentre è valida per lo sviluppo iniziale). Così ho dovuto cercare un modo per aggiustare sqldeveloper, e la soluzione è apparsa molto semplice: rimuovere la variabile di ambiente GNOME_DESKTOP_SESSION_ID:

% unset GNOME_DESKTOP_SESSION_ID
% sh ./sqldeveloper.sh

e io non ho nemmeno Gnome installato (ok le librerie, ma avere un session-id non me lo sarei mai aspettato).

Comunque dopo un po' il problema si è riverificato insistentemente, così ho applicato le seguenti due modifiche al file ~/.sqldeveloper/4.1.5/product.conf:

SetJavaHome /usr/lib/jvm/java-8-openjdk-amd64
SetSkipJ2SDKCheck true

Passare da [OpenSource Desktop] a OSX è giusto?

Miguel De Icaza ha pubblicato giorni fa un post piuttosto sconvolgente circa il suo passaggio definitivo ad OSX, il sistema operativo di casa Apple.

Prima di addentrarsi nei dettagli dell'articolo occorre ricordare chi Miguel De Icaza sia. Miguel è uno sviluppatore eccezionale, autore prima di Midnigth Commander, e poi fondatore e leader del progetto Gnome, uno dei desktop piu' famosi per ambienti Unix e Linux. E' anche fondatore di Mono, il "port" della tecnologia .NET di casa Microsoft su piattaforma Unix, ed è stato, fra le altre cose, fondatore di Ximian e ora di Xamarin. Miguel è una mente brillante, ha dato prova nel tempo di essere un hacker eccellente e di saper vedere nel sistema Open Source una ragione di essere e un modo di fare business. E' ovviamente un forte sostenitore del Free Software, e Mono inizialmente tanto criticato si è rivelata una delle sue ennesime scelte azzeccate: rendere i clienti Microsoft interessati anche al mondo Unix e Linux (free).

Solitamente gli hacker "impegnati" del calibro di Miguel non si lasciano "corrompere" dal mondo Apple. Parliamo di gente che è in grado di aggiustare i driver del proprio computer se non funzionano, e quindi di persone che non devono aspettare un qualche rilascio su mainstream o una patch solo per avere funzionante il tasto del volume del loro nuovo portatile.

Ecco quindi perche' il post di Miguel è sembrato sconvolgente.

E il cambiamento di Miguel verso il mondo Apple era gia' stato annunciato da un precedente post in cui spiegava come Linux avesse perso la corsa al desktop. http://tirania.org/blog/archive/2012/Aug-29.html

Ultimamente la discussione sui desktop alternativi a OSX e a Microsoft Windows diviene sempre piu' serrata, e molti utenti sui forum continuano a chiedere a gran voce supporto per i loro computer.

Il post di Miguel sostanzialmente puo' essere riassunto in "uso OSX perche' l'hardware funziona e ho accesso ad un sistema Unix", pensiero condiviso da sempre piu' hacker. Perché OSX funziona? Beh tutto sommato è semplice: la Apple fornisce un sistema completo, ovvero hardware e software. Ne consegue che la Apple ha le specifiche hardware prima ancora di installare il software, e quindi puo' creare il connubio perfetto cambiando il software ad-hoc o ricercando hardware differente e meglio compatibile. E tipicamente un utente Apple non farà modifiche all'hardware se non per sostituire un componente rotto con uno rigorosamente Apple (e rigorosamente bianco con una mela morsicata sopra).

Questa cosa mi ricorda molto le workstation Sun: funzionava tutto alla perfezione, e vi erano perfino comandi appositi per controllare le schede grafiche 3D, e tutto questo era possibile perché chi forniva il software era, prima di tutto, un fornitore hardware.

Nello scenario del commodity hardware la situazione é invece differente: Microsoft stringe da sempre alleanze con i produttori di hardware per avere la possibilità di fornire driver di (mediocre) qualità. Di contro, i sistemi liberi si trovano nella difficoltà di non aver accesso a tutto l'hardware esistente, come pure di non avere sufficiente forza lavoro per implementare nuovi driver e stare al passo con il mercato. Certo, fino a che i driver si possono appoggiare a degli standard il gioco regge. O meglio puo' reggere: l'hardware puo' infatti essere affetto da bug, e non sempre questi sono di facile soluzione. In tutto questo chi produce anche l'hardware si trova nell'indiscussa posizione di vantaggio che gli consente di fornire ai clienti un prodotto finito solo quando tutto sia ben testato: i bug vengono corretti o i problemi hardware vengono risolti sostituendo addirittura i componenti fallati.

In altre parole, il vero nocciolo della questione e' il supporto hardware e i relativi driver.

Gia', i driver, sono questi quelli che gli utenti chiedono a gran voce, e sono questi quei componenti che i sistemi open tanto faticano a fornire.

E si badi, non è un problema di compatibilità binaria, come descritto da Miguel: sistemi operativi come FreeBSD (che fondamentalmente importano "tutto") non sono messi bene nel ramo desktop, anzi sono ancora indietro rispetto a Linux.

E' quindi forse un problema legato all'API di [Open/Next]Step e alla scelta del linguaggio, Objective-C, rispetto all'uso ad esempio del C++ di KDE o del C (ad oggetti) di Gnome/GTK?

Io non penso, visto che il progetto GNUStep, fondamentalmente una implementazione libera della suddetta API compatibile con l'implementazione OSX, non ha portato piu' avanti il desktop Linux. Infatti, nonostante WindowMaker sia un ottimo window manager, e uno dei miei preferiti quando ero un'apprendista unixiano, non mi pare sia uno dei piu' apprezzati, anzi credo di poter affermare che ricopre un ruolo di nicchia. Si lo so, WindowMaker e GNUStep sono progetti tutto sommato separati e GNUStep non necessita nemmeno di un window manager, ma mi si passi il ragionamento.

La soluzione quindi e' forse condividere la ricerca sui driver open in modo che tutti i vari sistemi possano ispirarsi a risultati gia' ottenuti per incrementare il loro supporto? Non mi pare nemmeno questa la strada, visto le forti discrepanze fra i vari OS.

Creare allora livelli di astrazioni che mascherino l'hardware (ad es. Solid di KDE)? Si, sulla carta, ma alla fine quello che capita e' che ogni sistema prima o poi reinventa un pezzo di ruota. Ad esempio Gnome e' ormai fortemente ispirato a Linux, e quindi di difficile adattamento a BSD; PCBSD ha scelto deliberatamente di riscrivere quasi tutti i tool gia' inclusi in KDE piuttosto che "adattarli", e cosi' via.

Allora la soluzione e' prendere un sistema OSX che funziona out-of-the-box?

Beh, saro' forse un purista, ma non penso sia nemmeno questa la soluzione. Anzi, penso sia la morte del sistema Open Source. Eh si, perche' se e' vero che tutti noi abbiamo un lavoro da fare e un sistema che non si blocca e' meglio di uno che ha dei problemi, comprare un sistema proprietario, per quanto buono sia, significa ammettere esplicitamente il fallimento del movimento Open Source e negare il nostro supporto ad esso.

Vale la pena rifletterci.

Linus, Gnome, KDE e l'insoddisfazione

Si è parlato tanto in passato della migrazione di Linus Torvalds da KDE a Gnome, e in effetti i toni con i quali Linus ha denigrato KDE 4 sono stati...beh, nel solito stile di Linus (ossia piuttosto feroci).

Eppure sembra che alla fine nemmeno il progetto Gnome, con il rilascio di Gnome 3 (che è rivoluzionario esattamente come lo fu KDE all'epoca della release 4) non piace a Linus.

Non penso che la community Gnome debba essere triste di questo, come pure non penso che sia una vendetta di KDE, penso semplicemente che Linus, come tanti altri utenti, sia restio ai cambiamenti radicali. Specialmente quando questi cambiamenti non sono ad opera sua!

Xamarin, Nat e il passato che torna (?)

Miguel De Icaza, padre di Gnome e di Mono ha dato vita ad una nuova compagnia per promuovere lo sviluppo di Mono, con particolare riferimento ai dispositivi mobile. La nuova compagnia si chiama Xamarin  e il nome ricorda molto da vicino una precedente compagnia di Miguel: Ximian. Ebbene a quanto pare la somiglianza fra Xamarin e Ximian non e' solo nel nome: Miguel ha annunciato che Nat Friedman si unira' al team di Xamarin, e lo stesso Nat conferma sostenendo di essere addirittura un fondatore di Xamarin.
Il passato che ritorna?
Ad ogni modo in bocca al lupo alla nuova nata Xamarin, e speriamo che i risultati siano un po' migliori di quelli di Ximian, che a parte essere acquisita da Novell non ha poi prodotto quel tanto ambito desktop-super-integrato basato su Gnome!

Gnome 3 and KDE 4.6.2

On April 6th 2011 Gnome released a very important "software compilation": the Gnome 3 desktop. I've tested it during the development time and I see it has been a really good work, very innovative, maybe too much, and for this reason I believe this new version of Gnome will suffer about all the problems the KDE 4 release had. Both these releases deeply changes the approach to the computing, not only to the desktop, and therefore users will take time to get used to the new interface. I'm sure Gnome 3 will get rid of all problems quickly, and users will start loving this new desktop.
An interesting blog post from one of the founders of the Gnome Project briefly shows the history of the Gnome desktop; I'm quite surprised the globally-known leader of the first release of Gnome, Miguel De Icaza did not blog about this important release and did not put an "I am Gnome" icon on his blog neither.

On April 6th 2011 something else happened: KDE 4.6.2 was released! While this is a minor release, especially if compared to the Gnome 3 one, it is another important piece of history for my favourite desktop. And someone is already talking about KDE 5, even if I believe this will happen when Qt 5 will be released.

Well, just to joke around the "I am Gnome" image that many bloggers are using, I have produced a small "I am KDE" version of it. This is clearly a joke, there is no need to start a figth!

Gnome 3 posticipato? Niente panico, è un pesce d'Aprile!

Questa mattina la mia attenzione e' stata catturata da un post con uno strano titolo su planet Gnome che indicava che Gnome 3 (in uscita il 6 Aprile) sarebbe stato posticipato a Settembre 2011. Qualche secondo dopo ho realizzato che si trattava di un non tanto riuscito pesce d'Aprile (infatti il post ha la data 1 Aprile). Dico non tanto riuscito perche' francamente il messaggio non faceva ridere per niente, solitamente si cercano messaggi scherzosi sull'argomento tecnico che si sta trattando. Addirittura il post in questione ha scatenato il panico in qualche utente/lettore/blogger non attento che si e' lanciato in campagne disperate di sostegno del release team (qui e anche qui). Ora, qualsiasi release team di qualunque progetto OpenSource ha tutto il mio sostegno indiscriminato, ma era sufficiente leggere la mail circolata in mailing list development  come suggerito dal post-pesce-d'Aprile per rendersi conto che Gnome 3.0.0 verra' regolarmente rilasciato il 6 Aprile 2011.

Ai piu' sembrera' che anche in questo caso io stia pendendo per KDE rispetto a Gnome, ma effettivamente questo post e' sicuramente piu' esilarante del suo rivale Gnome...

L'integrazioe di Gnome

Aaron Seigo ha pubblicato un ottimo post riguardante l'atteggiamento piuttosto Gnome-centric e isolato della community Gnome, che tende ad andare avanti per la propria strada sempre e comunque senza volersi integrare con altri stack software. Questo e' uno dei motivi politici che mi ha sempre spinto a considerare KDE un progetto nettamente superiore, non solo per la tecnologia, ma anche per la mentalita' Free che ha sempre avuto.

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