Korona @ OpenSolaris

Il progetto Korona ha pubblicato una interessante survey su cosa gli utenti vorrebbero del nuovo KDE 4 su piattaforma OpenSolaris. Da quanto emerge dalla survey, come prevedibile, gli utenti sono disponibili a rinunciare ad alcune funzionalità pur di avere un desktop completo ed aggiornato.

KDE vs Gnome: la mia versione

Questo non vuole essere un post-flame sull'annosa e annoiante battaglia su quale dei due desktop sia meglio.

Questo è solo un post che cita alcune mie considerazioni sul perché uso KDE, su cosa vorrei in KDE e cosa ne penso di Gnome.

Ho iniziato ad usare KDE fin dalla prima versione, quella che, molti non lo ricorderanno, aveva un aspetto simile a Microsoft Windows, le icone grigie e gialle (o era arancione) e quei bellissimi titoli della finestra che scorrevano se troppo lunghi per essere visualizzati. Da allora sono rimasto fedele a questo desktop e sono passato attraverso tutte le versioni, ricompilandole a dovere ogni volta che ne usciva una versione nuova, fino alla 3.3 (quando ancora compilavo ed usavo Liquid)...poi mi sono affidato ai vari package manager per la sua installazione. Nel contempo ho sempre tenuto d'occhio Gnome, e devo dire che di passi in avanti ne ha fatti molti, soprattutto con la versione 2 che ha portato un po' d'ordine e coerenza nelle librerie e nelle interfacce. Ho studiato le librerie Qt e le GTK+/Gnome, ed essendo un programmatore ad oggetti mi hanno sempre attirato di piu' le Qt, pur riconoscendo l'estrema potenza delle Gnome. Dopotutto le Qt sono librerie C++ che aggiungo quel supporto run-time che le Gnome hanno implementato in C, quindi le due non sono concettualmente differenti. Ma non voglio parlare di differenze tecniche, quanto di differenze di utilizzo.

Il KDE 4 è stato un massacro: la prima versione non funzionava a dovere, mancava di molte applicazioni (perfino una per la stampa!) e il desktop non era per niente configurabile. Oggi, con la 4.4 siamo ad un desktop particolarmente completo. 

Veniamo alle differenze delle quali voglio parlare.

La prima è una differenza di concetto: KDE è un desktop altamente configurabile, Gnome è un desktop altamente semplificato. La scelta, coraggiosa, di Gnome con la versione 2 è stata quella di semplificare il desktop in modo che fosse utilizzabile con il minor numero di interazioni utente possibili. A prova di questo, molte delle applicazioni Gnome applicano le modifiche senza bisogno di passare per pulsanti "Applica" o "Ok", ricalcando in questo lo stile dell'Apple OSX. KDE, di contro, richiede che l'utente configuri ogni aspetto del desktop e sappia di dover applicare le modifiche per renderle attive. Quale scelta paga di piu'? La scelta di Gnome si è rivelata vincente: Ubuntu deve a mio avviso la sua grande diffusione proprio a questa scelta. Un desktop semplice, che assomigli per impostazione e concetto a quello di OSX, e che non richieda all'utente particolari configurazioni o noiose finestre di dialogo ha permesso l'utilizzo di sistemi GNU/LInux anche agli utenti che non sanno nemmeno fare lo spelling di "Sistema Operativo". Inoltre il dekstop Gnome risulta piu' leggero di quello KDE, l'accelerazione grafica funziona senza intoppi e l'apertura di finestre e applicazioni è veloce. Insomma, Gnome rinuncia ad un po' di effetti grafici, ad un po' di look per dare molto feel. 

A questo punto sembrerebbe che Gnome sia molto meglio di KDE. Eppure non è così per me: le applicazioni Gnome, con la loro mentalità "semplificata" sono poco personalizzabili per utenti evoluti. Prendiamo un esempio, anzi l'esempio: KMail. KMail è il client di posta di KDE, per me l'application killer dell'intero desktop. Ho usato KMail fino dalla versione KDEv1, mi sono innamorato di quella del KDEv2, ho iniziato ad essere drogato da quella del KDEv3 e ora sono dipendente da essa. KMail è il client perfetto, permette di fare qualunque cosa ed ha molti strumenti integrati. La sua controparte è Evolution, che invece richiede molti plugins per fare le stesse che KMail fa "gratis" (ad esempio l'antispam) e manca di molte personalizzazioni. Ad esempio in KMail posso configurare facilmente le stringhe di risposta dei messaggi, in Evolution no. E se questa sembra una motivazione scarsa, si pensi alla gestione di piu' account e-mail: KMail consente di impostare una lista di SMTP da usare messaggio per messaggio, Evolution solo account per account. Questo significa che mentre con KMail posso inviare una e-mail dell'account gmail con l'SMTP di Fastweb, in Evolution dovrei mandarla solo con l'SMTP di Google. Una bella limitazione!

Per quello che riguarda l'esplorazione di file e cartelle, KDE stravince. Già Konqueror era egregio nel fare il suo lavoro, ma Dolphin ormai lo supera di gran lunga. Di contro, Nautilus mostra ancora una interfaccia vecchio stile, con pochi effetti. Già, gli effetti, KDE ha puntato molto sugli effetti, mentre Gnome ha puntato molto sulla praticità.

L'idea stessa del Plasma Workspace la dice lunga: ogni elemento è un plasmoid, ossia un componente contenuto o contenitore. Sparisce il concetto di pannello principale, al suo posto vi è quello di oggetti contenuti in un workspace e che contengono altri oggetti. Ecco allora che una applicazione che gira sul desktop può essere inserita nel pannello. Per chi ha lavorato su middleware e sistemi a formiche, o ad agenti, questa idea non appare nuova, ma sicuramente piace molto.

Quindi in realtà KDE è perfetto? No, certo che no. Il Desktop è ancora lento, e la gestione della rete è pessima. Mentre il Network Manager di Gnome funziona al primo colpo con modem UMTS e reti wifi, l'applet di KDE non riesce a collegarsi a reti wifi-psa e non riconosce nemmeno i modem UMTS.

E a livello di diffusione? Beh, Gnome è molto piu' diffuso di KDE, complici anche le distribuzioni che tendono ad usare Gnome al posto di KDE. Di fatto esiste solo la Kubuntu come distribuzione "seria" che utilizzi KDE. Il fatto è che molti produttori/distributori preferiscono Gnome per le personalizzazioni, è questo il caso di OpenSolaris con Time Slider, disponibile per Nautilus ma non per Dolphin.

Insomma, Gnome è un desktop molto promettente, con un'API che ha dovuto subire diverse modifiche per essere inquadrata nell'ottica di un desktop omogeneo. La velocità e la semplicità del desktop lo rendono ideale per molti utilizzi, ma la mancanza di personalizzazioni avanzate lo rende inusabile per utenti evoluti. Di contro, il KDE è molto omogeneo, completo, e bello da usare, ma è ancora piuttosto pachidermico e manca di applet di rete funzionanti.

Oxygen Molecule (finalmente!)

Oggi ho scoperto un nuovo tema, denominato Oxygen Molecule per le applicazione GTK+ che le fa assomigliare in modo incredibile alle applicazioni native KDE con tema Oxygen. Ottimo lavoro, era proprio ora! In effetti la differenza di stile fra i due tipi di applicazioni mi dava un po' fastidio, mentre ora Eclipse  e Firefox sono perfettamente integrate nel mio desktop KDE.

OpenSolaris: boot testuale

In certi casi puo' essere necessario osservare cosa il sistema sta facendo al boot, e per questo occorre intervenire sulla configurazione di Grub di OpenSolaris. Le cose da fare sono le seguenti:

1. entrare nella modalità editing di Grub (e) o editare il file di avvio;
2. rimuovere la linea con splashimage
3. rimuovere la linea con foreground
4. rimuovere la linea con background
5. posizionarsi sulla linea che contiene la dicitura kernel e cambiare l'ultimo argomento console settandone il valore da graphic a text
6. effettuare il boot (b)

pfSense e default drop all su static route

Ho montato un firewall pfSense dotato di regole di static routing sulla stessa interfaccia: i pacchetti destinati alla rete X venivano smistati in ingresso e uscita dall'interfaccia LAN del firewall. Eppure i pacchetti non passavano, e dopo qualche secondo la connessione veniva interrotta. Il problema è nello state analyzer del firewall, che dopo qualche secondo si accorge del traffico da e per l'interfaccia LAN e blocca la connessione. La soluzione è quella di abilitare la voce Bypass firewall rules for traffic on the same interface dal menu' System->Advanced. In questo modo pf non considera lo stato dei pacchetti che viaggiano sulla medesima interfaccia e non getta la connessione.

iCaseSensitive

Ho scoperto, con meraviglia (anche se ormai non bisognerebbe piu' meravigliarsi di casa Apple) che i Mac OS X recenti accettano molti comandi da terminale in modo case-insensitive. Sebbene a prima vista questa possa sembrare un'idea geniale, la trovo penalizzante per un sistema Unix. Nella mia mente Unix è sempre stato un sistema rigoroso, che pretende che si sappia cosa si sta facendo (basti pensare alla differenza fra le opzioni di un comando GNU e uno non GNU). Ebbene questa mossa, fatta probabilmente per consentire ai meno esperti di fare copia e incolla di qualche comando da una pagina web, rischia di lanciare molti utonti nel ruolo di amministratori portandoli a danneggiare il loro sistema.

Non ho avuto tempo per verificare se il trucco dei comandi case-insensitive (si potrebbe dire che la Apple ha inventato la i-caseSensitive) sia realizzato tramite un alias, link o altro. Mah!

Licenze diverse? Beh naturale, la configurazione è diversa!

Qualche giorno fa stavo rileggendo un vecchio libro sull'architettura interna di Microsoft Windows 2000. Pur essendo datato, il libro presenta concetti e implementazioni comuni a molti dei sistemi di casa Microsoft, anche i piu' recenti. Ad un certo punto la mia attenzione è stata colpita dalla configurazione di memoria della piattaforma Microsoft, che dipende dalla licenza e dal tipo di sistema utilizzato: se si usa Microsoft Windows 2000 (workstation) si ha una configurazione classica di 3 GB di spazio utente e 1 GB di spazio kernel; se si usa la configurazione Microsoft Windows 2000 Data Center (server) si ha una configurazione simmetrica di 2 + 2 GB. 

Cosa c'è di strano in questo?

Sicuramente il fatto delle licenze! Chi conosce bene altri sistemi operativi sa che la configurazione di memoria dipende da un qualche flag o macro di compilazione, ad esempio da PAGE_OFFSET in Linux (ad esempio x86/asm/page_32_type.h), e variare la licenza per una semplice opzione di compilazione mi sembra ridicolo. Certo, la licenza differente non implica che tutta la differenza di costo e utilizzo sia dovuta alla differente configurazione di memoria, ma che è dovuta anche a ciò.

Sarebbe bene che tutte quelle persone che consigliano i sistemi proprietari sulla base di ridicole affermazioni sul valore aggiunto o sulla serietà delle aziende riflettessero su questo episodio. E iniziassero anche a leggere qualche cosa di piu' tecnico che una semplice brochure.

Drop owned

A volte è necessario eliminare da un database una serie di tabelle apparteneneti ad un determinato utente. Una soluzione è quella di interrogare il catalogo di sistema, pg_class in particolare, per trovare tutti gli oggetti assegnati ad un utente. Tuttavia PostgreSQL contiene anche il comodo comando DROP OWNED che consente di eliminare in un sol colpo tutti gli oggetti che appartengono ad un dato utente. Inutile dirlo, il comando è molto pericoloso, e quindi a volte è bene riflettere sulle sue implicazioni.

Ubuntu Netbook: gave up waiting for root device

Qualche giorno fa ho avuto una amara sorpresa accendendo il mio netbook con Ubuntu 9.1: il sistema risultava inchiodato, schermo nero, nessun messaggio, nessun errore. Ho deciso quindi di editare la stanza di grub in questione rimuovendo il flag quiet per vedere cosa il computer stesse facendo durante il boot, e alla fine mi sono trovato lanciato in una shell busybox perché il sistema non riusciva a trovare la root. Ebbene la soluzione a questo problema mi è venuta in mente osservando questo bug: in sostanza ho rimosso dalla stanza di grub la linea con search, ho rimosso l'uuid del disco root e l'ho sostituito con la partizione su cui risiedeva la root (per me /dev/sda1) e ho aggiunto il parametro rootdelay=90. Questa volta il boot ha funzionato, dopodiché ho provveduto a fare un upgrade del sistema e il problema si è rimosso completamente.

Cari spala-neve...

...capisco che non vi piaccia dover lavorare la notte, al freddo, passando avanti e indietro per le stesse strade cercando di renderle pulite. Capisco anche che ci mettete dell'impegno nel vostro lavoro. Capisco anche che senza di voi le strade sarebbe praticamente impercorribili. Quello che però non capisco è per quale motivo continuate ostinatamente a "sigillare" le auto parcheggiate ai bordi delle strade con i mucchi di neve che togliete dal centro della strada.

Capisco benissimo che fisicamente è impossibile non ammucchiare la neve da qualche parte, capisco anche che geometricamente non potete che ammucchiare la neve ai bordi della strada. Però anche voi, cercate di capire: se ammucchiate neve fino all'altezza dei finestrini, per tutta la lunghezza della macchina e altrettanta davanti al muso e al baule, io non riesco ad uscire dal pargheggio! E credetemi, non sto facendo la vittima, non sono l'unico a cui è capitato e non è nemmeno questa la prima volta a cui assisto a tali scene.

Pertanto vi chiedo cortesemente, quando spalate tonnellate di neve dall'alto dei vostri mezzi, cercate di ricordarvi delle auto parcheggiate sul bordo della strada. E magari proponete anche che qualcuno, armato di badile manuale, liberi eventualmente i cumuli di neve che accumulate sulle banchine. Perché se è importante che il traffico ritorni a fluire, è altrettanto importante che i pedoni non rischino di cadere, non essere visti, eccetera solo per far passare qualche mezzo inquinante.

Caricare una immagine dal bundle di una applicazione RCP

Il caricamento di una immagine contenuta in un bundle ma non nell'ImageRepository di una applicazione RCP non è un'operazione così banale come si potrebbe pensare, soprattutto se quello che serve non è tanto l'immagine ma i byte legati ad essa. In questo caso occorre infatti avere la possibilità di aprire uno stream verso l'immagine, e quindi si deve poter recuperare esattamente la posizione dell'immagine su disco.

Il primo passo è quello di ottenere il bundleimg corrente, e da esso ottenere l'URL dell'immagine con percorso assoluto "relativamente" al bundle stesso. In altre parole, se l'immagine si trova nella cartella del bundle, il percorso deve essere reso relativo ovvero deve diventare /img. L'URL così ottenuta è in una forma strana, come ad esempio:

bundleentry://33.fwk43086831/img/logo.png

Questo URL deve essere tradotto in una forma che abbia senso, ovvero in un percorso valido per il file system: questo viene fatto mediante il FileLocator. Ottenuto quindi l'URL effettivo (valido per il file system) dell'immagine, è possibile costruire un File e da esso un FileInputStream per ottenere i byte dell'immagine stessa.

In sostanza il codice risulta come il seguente:

Bundle bundle = Platform.getBundle( your.package.Activator.PLUGIN_ID );
URL url = bundle.getEntry(DEFAULT_LOGO_IMAGE_FILE_NAME);
URL fileURL = FileLocator.toFileURL( url );
File dummyImage = new File( fileURL.getPath() );
InputStream is = new FileInputStream(dummyImage);
byte[] bytes = new byte[ is.available() ];
is.read( bytes );

Problemi nell'esportazione di un prodotto RCP per Mac OS X

Come sottolineato in questo thread del forum ufficiale di RCP, l'esportazione di un prodotto per Mac OS X (Cocoa o Carbon) da una piattaforma di sviluppo Linux genera qualche problema. A dire il vero i problemi li hanno i Mac e il loro file system che non riconosce due file come distinti se il loro nome differisce solo per le maiuscole/minuscole. Comunque l'esportazione del prodotto RCP con i delta pack genera due directory .app all'interno della root finale (la cartella eclipse), una con l'iniziale del nome maiuscola e una con il nome tutto minuscolo. La soluzione sembra essere quella di eliminare la cartella con il nome maiuscolo e usare l'applicazione con il nome minuscolo.

Oppure si deve cambiare piattaforma di sviluppo e sperare in maggiore fortuna. Certo che dal team di Eclipse mi aspettavo fosse molto piu' semplice e immediato esportare un prodotto RCP per le varie piattaforme.