IppatsuBlog

La versione per Linux di Skype è costruita sul toolkit Qt, per cui si integra particolarmente bene nel look & feel di KDE. Skype però forza il tema “cleanlooks”, mentre le versioni più recenti di Kubuntu usano il tema Plastic (su KDE 3.5.9) o Oxygen (su KDE 4), per cui l’aspetto finale “stona” un po’ con il tema di default. Per fortuna si può costringere Skype a utilizzare il look & feel predefinito del sistema. Per farlo è sufficiente lanciarlo aggiungendo lo switch --disable-cleanlooks:

skype --disable-cleanlooks

L’aspetto di Skype su KDE4 è quello che potete vedere nello screenshot qui sotto.

Trucco per Kubuntu per accelerare l’avvio delle applicazioni:

1. Create una cartella vuota ~/.compose-cache
2. Aprite un qualunque programma di KDE che contenga un componente per scrivere testo
3. La cartella ~/.compose-cache conterrà un file il cui nome è una stringa del tipo l4_024_313cb605_00280cc0

Le applicazioni KDE/Qt/GTK dovrebbero ora avviarsi in 50/150 ms in meno.

Ho testato questo trucco solo su Kubuntu, ma dovrebbe funzionare su qualunque altra distribuzione. Se la vostra cartella /var/cache/libx11/ però non è vuota, ad esempio per chi usa SuSE, allora questa piccola ottimizzazione è già attiva.

Per i curiosi: creare la cartella ~/.compose-cache attiva una ottimizzazione creata da Lubos Lunak un po’ di tempo fa che è stata riscritta e integrata in libx11. Di solito all’avvio le applicazioni leggono le informazioni sul metodo di input dal file /usr/share/X11/locale/<locale>/Compose. Il file Compose è piuttosto lungo e richiede un po’ di tempo per essere elaborato. libX11 può creare una cache delle informazioni estrapolate molto più veloce da leggere in seguito, ma ri-utilizzerà una cache solo se può accedervi in /var/cache/libx11/compose o in ~/.compose-cache, se tale cartella esiste già.

Ulteriori informazioni
Via Robert Knight’s blog

È possibile che un’interfaccia grafica per apt come Synaptic o Adept crashi durante l’installazione di pacchetti. Questo lascia il database di apt in uno stato inconsistente. Il messaggio di errore rivelatore del problema è questo:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

Che nella versione in italiano è tradotto come:

E: Impossibile ottenere il lock /var/lib/apt/lists/lock - open (11 Risorsa temporaneamente non disponibile) E: Impossibile creare un lock sulla directory di list

Per risolvere questo problema in genere è sufficiente eseguire in un terminale:

sudo fuser -vki /var/lib/dpkg/lock;sudo dpkg --configure -a

Daniel Dyer sta pubblicando sul suo blog una serie di articoli dedicati alla generazione di numeri casuali con Java. Tutti i programmatori Java prima o poi utilizzano la classe java.util.Random, che però va bene solo per semplici casi: necessità di una distribuzione uniforme e nessun requisito di sicurezza.

Per la crittografia usare java.util.Random è un peccato mortale: la classe da utilizzare in questo caso è java.security.SecureRandom. Per verificare quanto siano poco casuali i bit generati da java.util.Random fate riferimento a questa pagina: http://www.alife.co.uk/nonrandom/index.html.

Dyer coglie l’occasione per fare “pubblicità” al suo progetto opensource uncommons-maths, rilasciato sotto licenza Apache, che utilizza diversi motori casuali (Marsenne Twister, un generatore basato sugli automi cellulari che piacerebbe a Stephen Wolfram e un generatore basato su AES) e può generare numeri secondo diverse distribuzioni: uniforme, gaussiana, di Poisson, binomiale e esponenziale. È disponibile un demo che mostra in modo sensibile le diverse distribuzioni, basta eseguire sul proprio terminale preferito:

javaws https://uncommons-maths.dev.java.net/demo/demo.jnlp

Gli articoli pubblicati da mentre scrivo sono i seguenti:

• A Java Programmer’s Guide to Random Numbers, Part 1: Beyond java.util.Random
• A Java Programmer’s Guide to Random Numbers, Part 2: Not just coins and dice

Nei prossimi post della serie Dyer parlerà dei gradi di libertà nel mischiare un mazzo di carte e dei problemi da gestire quando si usano numeri casuali nella crittografia.

Nel suo profilo su LinkedIn Dyer scrive di avere esperienza nella programmazione di giochi online relativi a giochi d’azzardo: nessuna meraviglia che sia interessato alla generazione efficiente di numeri casuali (gli algoritmi random utilizzati da un programma che simuli la roulette può essere perfettamente corretto e “fair”: sono le regole del gioco a far sì che alla fine della giornata il vincitore sia sempre il banco).

Maven è un strumento molto utilizzato per gestire il ciclo di vita delle applicazioni sviluppate in Java. Per compilare tutti i sorgenti è sufficiente lanciare il comando:

mvn compile

Una cosa che all’inizio dell’uso di Maven mi era sembrata sorprendentemente ardua era creare un unico .jar contenente tutte le dipendenze necessarie per l’esecuzione del programma. La soluzione è molto semplice. Aprite il pom.xml del vostro progetto e aggiungete il maven-assembly-plugin:

    <build>
        <plugins>

            ...

            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>
                            jar-with-dependencies
                        </descriptorRef>
                    </descriptorRefs>
                    <archive>
                        <manifest>
                            <mainClass>
                                com.application.MainClass
                            </mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>

            ...

        </plugins>
    </build>

Sostituite com.application.MainClass con il nome della classe contenente il main (compreso il package) e salvate il pom. Per generare il file jar eseguite:

mvn assembly:assembly