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

Compilando le binutils 2.18 su Kubuntu Hardy Heron 8.04 beta l’installazione falliva con il seguente errore:

Making info in doc
make[3]: Entering directory `/usr/src/binutils-2.18/buildit/bfd/doc'
restore=: && backupdir=".am$$" && \
        rm -rf $backupdir && mkdir $backupdir && \
        if (/usr/src/binutils-2.18/missing makeinfo --split-size=5000000
--split-size=5000000 --version) >/dev/null 2>&1; then \
          for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9]
bfd.i[0-9][0-9]; do \
            if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
          done; \
        else :; fi && \
        if /usr/src/binutils-2.18/missing makeinfo --split-size=5000000
--split-size=5000000   -I ../../../bfd/doc \
         -o bfd.info `test -f 'bfd.texinfo' || echo
'../../../bfd/doc/'`bfd.texinfo; \
        then \
          rc=0; \
        else \
          rc=$?; \
          $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \
        fi; \
        rm -rf $backupdir; exit $rc
WARNING: `makeinfo' is missing on your system.  You should only need it if
         you modified a `.texi' or `.texinfo' file, or any other file
         indirectly affecting the aspect of the manual.  The spurious
         call might also be the consequence of using a buggy `make' (AIX,
         DU, IRIX).  You might want to install the `Texinfo' package or
         the `GNU make' package.  Grab either from any GNU archive site.
make[3]: *** [bfd.info] Error 1
make[3]: Leaving directory `/usr/src/binutils-2.18/buildit/bfd/doc'
Making info in po
make[3]: Entering directory `/usr/src/binutils-2.18/buildit/bfd/po'
make[3]: Nothing to be done for `info'.
make[3]: Leaving directory `/usr/src/binutils-2.18/buildit/bfd/po'
make[3]: Entering directory `/usr/src/binutils-2.18/buildit/bfd'
make[3]: Nothing to be done for `info-am'.
make[3]: Leaving directory `/usr/src/binutils-2.18/buildit/bfd'
make[2]: *** [info-recursive] Error 1
make[2]: Leaving directory `/usr/src/binutils-2.18/buildit/bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory `/usr/src/binutils-2.18/buildit'
make: *** [all] Error 2

L’errore è dovuto a un bug nel codice del configure (http://bugs.sourcemage.org/show_bug.cgi?id=14015). Si può risolvere in due modi:

1. Installando una versione di makeinfo <=4.9 (che su *Ubuntu Hardy si riduce a installare questo pacchetto per Gutsy ma funzionante anche su Hardy texinfo_4.8.dfsg.1-6_i386.deb)
2. Metodo più corretto: applicando questa patch: http://bugs.sourcemage.org/attachment.cgi?id=6971

Scusate il post atipico ma ho perso mezz’ora della giornata prima di capire dove mettere le mani, e magari posso risparmiare il tempo perso a qualcun’altro.

È 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