POSTA
LINUX
Programmazione embedded:
SOLUZIONI
un plus per Linux
INTERNET
CAD
SVILUPPO
GIOCHI
RUBRICHE
Di Marco Fioretti
Telefoni, console, videoregistratori: come si sviluppa
per il pinguino nascosto nei più disparati dispositivi.
I
computer da tavolo e i server sono
soltanto una piccola parte degli elaboratori esistenti. Oggi gli oggetti
contenenti un microprocessore sofisticato sono innumerevoli e molti di
essi sono di uso assolutamente comune: telefonini, lavatrici, impianti antifurto, videoregistratori, console per
giochi, centraline per home automation e mille altri. Quando un microprocessore e il relativo software vengono inseriti all’interno di un generico macchinario, per estenderne le capacità in qualsiasi maniera, vengono
usualmente definiti embedded, cioè
integrati. Inserire un mini-processore
(microcontroller) in un apparato per
controllarne il funzionamento non è
certo una novità. Fino a tempi relativamente recenti però, le capacità di
calcolo dei microcontroller embedded non erano in grado di far girare
che singoli programmi altamente ottimizzati. Molti processori embedded
attuali, anche se invisibili, sono invece abbastanza potenti da poter ospitare sistemi operativi veri e propri, a
volte anche real time . Allo stesso
tempo, anche se le distribuzioni più
popolari per desktop hanno ormai requisiti hardware uguali o quasi a
quelli di Windows, il kernel vero e
proprio di Linux ha bisogno soltanto
di poche centinaia di Kilobyte per
funzionare.
Questi fatti, uniti all’estrema flessibilità di Linux, hanno una conseguenza
particolarmente interessante per studenti e appassionati di informatica:
parecchi dispositivi elettronici utili
anche ai non specialisti, come gli impianti antifurto o di home automation
appena citati, oggi si possono costruire o personalizzare senza conoscenze
superspecializzate o apparecchiature
assai costose, almeno nei casi più
semplici. Soprattutto, questo è possibile scrivendo programmi o script con
tecniche abbastanza simili a quelle di
Linux per desktop o server. Il discorso
vale anche per i laboratori di informatica delle scuole, che potrebbero
preparare gli studenti a tecniche di
programmazione embedded di sicuro
interesse per il mercato del lavoro,
con spese e risorse davvero limitate
rispetto anche a pochi anni fa.
Un tutorial tecnico su queste attività
richiederebbe molto più spazio di
quello disponibile in questa rubrica.
Nel resto di questo articolo vedremo
però quali sono i concetti basilari che
occorre conoscere per comprendere i
vari manuali sull’argomento, cosa
aspettarsi e quali preparativi fare per
muovere i primi passi nel mondo di
Linux embedded.
Un po’ di terminologia
Tutti i tutorial e manuali per la programmazione embedded utilizzano
continuamente vari termini non
complicati ma probabilmente scono-
Distribuzioni Linux per uso embedded
D
ecidere quale distribuzione utilizzare è il primo problema di
molti nuovi utenti Linux e a questa regola non si sfugge nemmeno nel campo embedded. La prima scelta da fare è fra distribuzioni interamente Open Source, senza costi di licenza, o proprietarie,
con parte del codice più o meno chiuso e varie formule di supporto.
Oltre che per ovvi motivi etici, didattici o di costi, la prima scelta è
più conveniente nel caso in cui si voglia modificare più o meno pesantemente il kernel vero e proprio e si può fare affidamento soltanto sul supporto fornito online da mailing list e newsgroup.
Alcuni prodotti commerciali, d’altra parte, potrebbero offrire anche
kit hardware per sviluppatori, completi di schede, connettori, alimentatori e manuali stampati, a prezzi abbordabili per uso didattico o
comunque non-profit. L’alternativa Open Source più popolare è forse
ucLinux (www.uclinux.org) compatibile con decine di processori, da
300
quelli nei router Cisco a vari modelli di Arm, Coldfire, Dragonball, Microblaze e Intel i960. Anche la distribuzione Gentoo ha una versione
embedded (www.gentoo.org/proj/en/base/embedded/) con una comunità di sviluppo abbastanza attiva. Nel campo commerciale, i nomi più noti sono Wind River ( www.windriver.it ), Montavista
( www.mvista.com ), Freescale ( www.freescale.com ), TimeSys
(http://timesys.com/) e LynuxWorks (www.lynuxworks.com).
Esiste anche un consorzio (www.embedded-linux.org) che alcuni anni fa ha proposto una piattaforma comune per facilitare il porting di
applicazioni software fra versioni diverse di Linux embedded. Una
menzione d’onore in questo spazio va infine a Kaeil OS (www.koansoftware.com/kaeilos/), una distribuzione disponibile con licenza Gpl
sviluppata in Italia, con possibilità di supporto professionale, da
Koan Software.
PC Professionale - Dicembre 2007
RUBRICHE
LINUX
sciuti a chi non si è già inoltrato in
questo mondo, quindi prima di procedere è opportuno spiegarne il significato.
Lo stesso termine embedded non ha
un’interpretazione unica. Alcune applicazioni embedded usano versioni
pesantemente modificate di Linux
(vedi box), talmente diverse dall’originale che anche i programmi applicativi vanno scritti con criteri particolari. Questo è vero soprattutto
quando il kernel o i programmi devono assolutamente reagire a stimoli esterni in maniera praticamente
istantanea (real time), cioè con ritardi inferiori a qualche frazione di secondo. Un esempio familiare sono i
microprocessori che controllano freni o altri componenti delle automobili più moderne.
Altrettanto spesso però per embedded si intende qualsiasi applicazione
in cui potenza del processore, memoria e capacità di storage sono talmente ridotti rispetto ai normali
computer da impedire l’uso delle
stesse librerie e software applicativi
usati su quelle piattaforme. Quasi
sempre i sistemi embedded sono privi di disco rigido e hanno soltanto
pochi Megabyte di memoria flash.
Quest’ultima è la stessa memoria
usata nelle chiavi Usb o per ospitare
il software Bios nei Pc normali, diffusissima nel mondo embedded perché permette di conservare permanentemente dati e programmi essenziali in poco spazio e con consumi
molto ridotti.
Il modo più semplice per far pratica
di programmazione Linux embedded senza doversi trasformare in
progettisti hardware è l’acquisto di
un Pda basato su Linux o, meglio ancora, di un qualsiasi Single Board
Computer (Sbc), cioè di una singola
scheda contenente un processore
compatibile x86, memoria flash e le
periferiche più comuni come video
Vga, Ethernet, Usb e seriale. Alcuni
siti dove reperire informazioni su
Pda e Sbc supportati da Linux sono
nel box Risorse.
Per quanto riguarda il flusso di sviluppo software, i processori su cui si
caricano e fanno girare Linux e altri
programmi in modalità embedded
vengono chiamati target (bersaglio).
A volte lo stesso termine indica an-
che l’intera scheda o macchinario su
cui quei processori sono montati.
Il termine host (ospite) indica invece
il personal computer o server tradizionale su cui lo sviluppatore scrive
e compila i programmi per il target,
li carica nel target stesso e lo controlla. Un altro uso frequente dell’host è quello di fare da disco rigido
ausiliario per il target. Questo avviene soprattutto nella fase iniziale di
sviluppo del software, quando è utile provare diverse versioni di un programma e la loro dimensione complessiva supera quella della flash .
Per usufruire di questa funzionalità è
sufficiente installare sull’host lo stesso server Nfs (Network File System)
con cui si condividono partizioni fra
più computer Linux normali connessi in rete locale.
Architettura di base
I componenti essenziali di qualsiasi
ambiente Linux embedded sono un
boot loader per l’avvio del sistema, il
kernel vero e proprio, un programma di inizializzazione e uno stack
Tcp/Ip per le comunicazioni via Internet o rete locale. Il kernel non deve ovviamente essere lo stesso che
gira in un desktop, anche quando si
lavora su processori x86. Gli unici
compiti sicuramente necessari sono
la gestione della memoria, l’arbitraggio (scheduling) fra i vari processi e il controllo dei driver delle
poche periferiche eventualmente
presenti sulla scheda. A queste funzioni base si aggiungono, nel caso
dei sistemi real time, i contatori di
tempo e i relativi algoritmi di con-
trollo che garantiscono la risposta a
stimoli esterni entro i tempi richiesti.
Nel caso in cui si vogliano conservare permanentemente dei file sul target ed eseguirvi dei programmi applicativi, cioè quasi sempre, è necessario anche un file system che permetta di dividere la flash in partizioni e directory come accade nei normali Pc. I primi sistemi Linux embedded utilizzavano i file system
standard per Linux. Poiché questi
sono progettati non per memorie flash ma per normali dischi rigidi, divisi in blocchi e settori, era necessario
uno strato software supplementare
per emulare i blocchi e riconoscere,
evitandoli in maniera trasparente
per i programmi, le locazioni di memoria danneggiate.
In seguito si è passati, per aumentare le prestazioni, a file system scritti
specificamente per le flash, che non
hanno bisogno di questi componenti
ausiliari. Quello oggi più usato è
Jffs2 (Journalling Flash File System,
version
2,
http://sourceware.org/jffs2/), le cui
capacità sono descritte in dettaglio
nella pagina web http://sourceware.org/jffs2/jffs2-html/.
Configurazione
dell’ambiente
di sviluppo su Linux
Una volta scelto il target, occorre installare sull’host il compilatore e tutte le librerie necessarie per creare il
software per il target. Poiché i relativi pacchetti sono o quelli usati per la
programmazione standard su Linux,
Componenti principali di un sistema Linux embedded
Programmi applicativi e interfaccia utente
File system ottimizzato per memorie flash
Scheduler
Gestione memoria
Driver
KERNEL
Boot loader
Alcuni componenti dei sistemi Linux embedded sono gli stessi, o quasi, dei
desktop: shell, programmi applicativi da linea di comando, scheduler non real
time e alcuni driver. Altri, come le librerie grafiche, il file system o il gestore
della memoria, sono sviluppati appositamente per questi scenari.
301
PC Professionale - Dicembre 2007
RUBRICHE
LINUX
Ambiente di sviluppo per Linux embedded
Compilatore, debugger, librerie, linker...
SERVER DI RETE:
Nfs
Dhcpd
Tftpd
Minicom o Kermit
BOOT
LOADER
DRIVER PORTA
SERIALE
Interfaccia Jtag o Bdm
HOST
TARGET
Alcuni componenti dei sistemi Linux embedded sono gli stessi, o quasi, dei
desktop: shell, programmi applicativi da linea di comando, scheduler non real
time e alcuni driver. Altri, come le librerie grafiche, il file system o il gestore
della memoria, sono sviluppati appositamente per questi scenari.
su cui esiste una notevole documentazione, o altri molto specializzati forniti (quasi sempre) direttamente dal
fabbricante del target non ne parleremo ulteriormente in questa sede.
Oltre all’ambiente di compilazione
vero e proprio, per comunicare con il
target occorre un’interfaccia fisica in
via di estinzione nei desktop, quella
seriale. Anche se molti dispositivi,
soprattutto Sbc, hanno almeno una
porta Ethernet, il protocollo seriale
rimane infatti quello più comune in
questo segmento di mercato. Una
porta seriale può ridurre dimensioni
e costo dell’hardware ed è molto più
semplice e affidabile dal punto di vista software.
La comunicazione via ftp, telnet o
ssh richiede infatti, oltre ai relativi
client o server, anche uno stack
Tcp/Ip ed Ethernet funzionante e opportunamente configurato, cosa
niente affatto scontata in un sistema
embedded ancora in via di sviluppo.
Se l’ host ha un’interfaccia seriale,
per usarla sotto Linux basta invece
configurare opportunamente programmi come Minicom o Kermit. Entrambi hanno man page che descrivono funzionamento e opzioni per la
linea di comando in maniera abbastanza completa e permettono sia di
aprire una console sul target sia di
trasferire file fra quest’ultimo e l’host.
Caricamento
del software sul target
Alcuni sistemi embedded devono essere in grado di funzionare da soli,
mentre altri sono utili soltanto se collegati a un computer principale che
ne dirige le operazioni. Smartphone e
palmari sono gli esempi più comuni
della prima categoria: la seconda
comprende registratori di cassa, moduli antifurto e qualsiasi altro terminale intelligente che ha bisogno di essere continuamente connesso a una
rete locale per funzionare. Le modalità di caricamento e avvio di Linux e
dei vari applicativi che girano su di
esso possono essere abbastanza diverse nei due casi. I dispositivi isolati
devono essere caricati con tutto quello che gli serve per essere completamente autonomi dall’istante stesso in
cui vengono accesi. Quelli di tipo terminale, invece, potrebbero anche fare
a meno di avere una copia locale del
software, scaricandolo dalla rete locale con i metodi descritti più avanti.
Quando questo è possibile, l’unico
software da installare sulla scheda è il
boot loader che effettua lo scaricamento iniziale e lancia il kernel Linux.
La procedura per riscrivere effettivamente una flash da linea di comando
richiede utility che variano da target a
target, quindi non ne parleremo in
questo articolo. Il software da installare sull’host per permettere al target di
partire e configurarsi correttamente è
invece assolutamente standard. Le relative procedure sono infatti le stesse
utilizzate nel mondo Linux (e Windows) in qualsiasi caso si abbiano, in
una rete locale, dei client privi di disco rigido (diskless) su cui conservare
il proprio kernel.
Per partire, i client diskless non possono che scaricare, tramite la stessa rete
locale, l’intero kernel e qualsiasi altro
file sia loro necessario nella fase di avvio. Perché questo accada, le prime
cose di cui il target ha bisogno al momento dell’accensione sono il suo indirizzo Ip e il nome e la locazione in
rete del proprio kernel. L’host può fornire queste informazioni con lo stesso
Risorse
Per avere un’idea di quali modelli di Single board computer sono disponibili in Italia si possono visitare le pagine www.koansoftware.com/it/prd_sbc.htm e www.cjb.it/CPU-All-In-One.htm.
Una buona introduzione generale a Linux embedded, adatta a chi ha già esperienza di programmazione, è il tutorial “Embedded Linux applications: An overview” (www.ibm.com/developerworks/linux/library/l-embl.html). Nel 2004 il Linux Journal ha pubblicato una introduzione
in quattro parti alla programmazione embedded: l’Url dell’articolo finale, che contiene anche i
link alle puntate precedenti, è www.linuxjournal.com/article/8122. L’articolo in italiano www.linux.it/~rubini/docs/boot26/boot26.html spiega in maniera dettagliata le varie fasi di avvio di un
sistema Linux, embedded o no.
Una presentazione, sempre in italiano, sugli “Strumenti di sviluppo per Linux embedded”, piuttosto completa anche se non aggiornatissima, si può scaricare all’indirizzo http://free-electrons.com/doc/embedded_linux_tools_it.odp. Molte altre presentazioni in Italiano su questi temi sono disponibili su www.ingpozzi.it/semlinux/interventi.htm. Un elenco dei passi da eseguire per configurare Minicom per comunicare con un sistema embedded si trova infine nel manuale Red Hat per sviluppatori embedded, www.redhat.com/docs/manuals/edk/EDK-1.0-Manual/getting-started-guide/gsinstall.html.
302
PC Professionale - Dicembre 2007
RUBRICHE
LINUX
Un generico connettore Bdm (da www.hitex.com) per
debugging e recupero di schede embedded anche
nelle situazioni più critiche. Il connettore è in realtà
composto da un circuito racchiuso in un involucro che
va posto fra il target e l’host, a cui va collegato con un
normale cavo parallelo o Usb, nei modelli più veloci.
protocollo usato dai client Pc nelle
normali reti aziendali, quello Dhcp
(Dynamic Host Configuration Protocol): basta quindi configurare il relativo server, dhcpd, che è disponibile come pacchetto binario in tutte le distribuzioni Linux. Una volta scoperto
qual è il kernel di cui ha bisogno per
partire, il target deve ancora scaricarlo via rete. Il protocollo che praticamente tutti i target Linux sono sicuramente in grado di usare per scaricare
file è quello Tftp ( Trivial Ftp , cioè
“Ftp semplificato”). Come nel caso di
Dhcp, conoscere Tftp è quindi utile
non solo agli aspiranti programmatori
embedded ma anche, per esempio,
agli amministratori di un laboratorio
scolastico: mettere a disposizione degli studenti soltanto dei Pc diskless è
uno dei modi migliori per riciclare
computer altrimenti obsoleti, aumentando grandemente, allo stesso tempo, sicurezza e semplicità di amministrazione del sistema.
Pronto soccorso
via hardware
I componenti hardware e software
appena descritti sono sufficienti a
sviluppare e collaudare software embedded quando tutto va bene. Come
fare però quando il kernel del target
non riesce più a partire per un errore
di programmazione o perché i file
contenuti nella flash sono stati corrotti? In casi del genere nemmeno
l’interfaccia seriale è utilizzabile e
non servirebbe a nulla spegnere e
riaccendere il dispositivo, ma se la
scheda che ospita il target è stata
progettata con criterio non c’è pericolo. Per far fronte a questi problemi
l’industria elettronica ha sviluppato
da anni due interfacce standard: la
Jtag (Joint Test Action Group, uno
standard Ieee) e la Bdm (Background
Debug Mode). La prima è un protocollo di comunicazione usato principalmente per il collaudo, usualmente tramite la porta parallela di un Pc,
di qualsiasi tipo di circuito integrato
montato su una scheda. Nel nostro
caso, la Jtag è interessante soprattutto per connettersi al processore o alla
memoria flash presente sulla scheda
stessa. Anche Bdm, originariamente
sviluppata da Motorola, permette di
accedere direttamente agli stessi
componenti, sempre tramite la porta
parallela, o a volte quella Usb dell’host. L’uso di entrambe le interfacce nello sviluppo di software embedded è lo stesso: connettersi al processore target, anche se tutte le sue partizioni fossero vuote o corrotte e non
riuscisse a partire da solo, per caricare direttamente nella sua memoria
un kernel e poi avviarlo.
Sia Jtag sia Bdm richiedono connettori dedicati sul target e/o circuiti ausiliari collegati ai connettori stessi.
Dal punto di vista della configurazione dell’host, la cosa più importante è
ottenere il driver adatto per la porta
usata da quei connettori (parallela o
Usb), verificare che non entri in conflitto con altri driver per le stesse porte e rimuovere questi ultimi, o almeno disattivarli, in caso contrario.
Nulla impone che un’applicazione
embedded possa avere soltanto
un’interfaccia a carattere
o comunque estremamente spartana.
I toolkit grafici per Linux come Qtopia
mettono a disposizione
dei programmatori icone assai
gradevoli, menu a tendina, barre
di scorrimento e tanti altri elementi
comuni nei nostri desktop
(fonte: LinuxJournal.com).
303
PC Professionale - Dicembre 2007
Busybox: Linux
embedded si controlla
come un desktop
O
ggi è possibile controllare con Linux, usando le stesse utility, interfacce e linguaggi di
scripting già noti ai suoi utenti desktop, qualsiasi
oggetto che contenga un processore embedded
compatibile con Linux.
L’affermazione, per quanto indiscutibile in generale, potrebbe indurre parecchi utenti in errore, o
almeno creare qualche confusione. Potrebbe succedere, in particolare, di caricare su un processore embedded uno script shell già collaudato con
successo su un normale server o workstation e
lanciarlo da una linea di comando apparentemente identica a quella di quegli altri computer solo
per vederlo fallire con un messaggio d’errore simile a “comando o opzione sconosciuti”. Quasi
sempre, le ragioni per messaggi di questo tipo
sono due. La prima è che nello script è stato chiamato qualche comando particolare, non incluso
in tutte le distribuzioni di Linux, oppure incluso
ma in una diversa directory del file system. Quando questo si verifica, basta aggiungere i file che
mancano, ammesso che ci sia ancora spazio disponibile. L’altro caso, che è quello discusso in
questo articolo, è quando si esegue un comando
o si lancia un programma che, pur essendo effettivamente presente nel sistema ha un comportamento diverso da quello che conosciamo. Questo
avviene perché quel programma è effettivamente
diverso da quello installato presente in un normale server o desktop Gnu/Linux.
In un sistema embedded è molto probabile che
queste versioni modificate non siano altro che un
unico file eseguibile, capace di comportarsi in
molte maniere diverse. Si tratta di Busybox
(www.busybox.net) un programma sviluppato
per sostituire da solo parecchie decine delle utility tradizionali della linea di comando Unix: bzip2,
grep, gzip, reboot, sed, tar, wget e molte altre. Sono disponibili anche quasi tutte le capacità essenziali dell’editor Vim. In effetti, quasi qualsiasi comando normalmente presente negli script di avvio di un sistema Gnu/Linux o comunque necessario per la sua amministrazione è sostituibile da
Busybox. Il motivo per cui è stato sviluppato questo applicativo è ovvio: un singolo eseguibile può
eliminare completamente la duplicazione di codice fra diversi programmi, quindi Busybox occupa
molto meno spazio della somma delle utility che
sostituisce. La struttura del codice sorgente facilita anche l’aggiunta di altri programmi da parte di
sviluppatori indipendenti, oppure la rimozione di
quelli non necessari per ridurre ulteriormente lo
spazio necessario. Tutto questo fa di Busybox
uno strumento prezioso non solo nelle piat-
RUBRICHE
LINUX
taforme embedded vere e proprie, in cui tutto il software deve entrare in pochi Megabyte di memoria flash, ma anche in floppy disk
o altri sistemi di recupero, che hanno limiti di
spazio abbastanza simili. Un altro fattore del
successo di Busybox sta nel fatto che, almeno in prima approssimazione, è possibile
usarlo senza nemmeno conoscere la sua esistenza. Il modo più elementare di usare Busybox è invocarne il nome seguito da quello
del programma di cui si ha bisogno e da
eventuali argomenti per quest’ultimo. Scrivendo quindi:
# busybox vim prova.txt
in una shell, Busybox aprirà, comportandosi
come l’editor Vim, il file “prova.txt”. La pro-
Aumentano le capacità
di Group Office
G
roup-Office (www.group-office.com) è una
suite Php per l’organizzazione dell’ufficio, disponibile in varie versioni tutte interamente utilizzabili tramite web browser. Le funzioni di base includono rubrica condivisa con campi personalizzabili,
calendario, client di posta elettronica, sincronizzazione dei relativi dati con Pda o Microsoft Outlook,
file e project manager, gestione delle fatture e un
semplice negozio elettronico. Avvisi o bollettini ai
clienti creati con OpenOffice o Microsoft Office
possono essere spediti a una mailing list di contatti direttamente dall’interno del programma. A partire da novembre 2007 la versione professionale di
Group-Office include un applet Java che sincronizza anche i file sul disco locale di ogni utente con le
copie presenti sul server centrale. Group-Office
mette anche a disposizione dell’amministratore di
sistema moduli speciali per gestire gli utenti e l’intero funzionamento del sito web. Un nuovo sistema di helpdesk, con notifica automatica via email o
browser delle richieste dei clienti, mantiene un database centralizzato con la storia completa delle
stesse richieste. Il sito web contiene anche un demo online dell’intero programma.
cedura di installazione crea però anche tanti
link all’eseguibile Busybox quanti sono i programmi che esso sostituisce e ogni link ha il
nome di uno di quei programmi. Il risultato è
che quando si ha bisogno, per esempio, di
comprimere un file con gzip e si digita questa stringa nella linea di comando, Busybox
capisce da quale dei link suddetti è stato
chiamato e si comporta, nei limiti delle sue
capacità, come il programma originario.
Questa flessibilità ed efficienza hanno un
prezzo, che è poi quello già accennato. Sia
per mantenere al minimo le dimensioni del
programma sia per facilità di sviluppo, Busybox non contiene tutte le funzioni e opzioni
delle utility che sostituisce. È proprio questo
che dà luogo, se l’utente non ne è al corrente, ai messaggi d’errore menzionati all’inizio
dell’articolo. Le opzioni supportate, d’altra
parte, si comportano in maniera quasi identica a quelle dei programmi originari e le differenze sono documentate, quindi con un minimo di preparazione o di ricorso al manuale
online si possono evitare brutte sorprese.
Se Busybox non basta
Nonostante le sue notevoli capacità, può
capitare di aver bisogno di un programma,
soprattutto un server, che Busybox non è in
grado di rimpiazzare. Esistono comunque diversi progetti indipendenti, descritti nella
pagina www.busybox.net/tinyutils.html, che
colmano questo vuoto: i più utili sono Dropbear (server e client Ssh in meno di 100 Kilobyte) e ssmtp per la posta elettronica.
Red Hat e Novell guardano all’Asia
C
ina, India e il resto dell’Asia sono in fase di rapida espansione anche per quanto riguarda
l’uso del software Open Source a livello istituzionale e due dei più grossi fornitori di questo software, Red Hat e Novell, hanno entrambi progetti molto ambiziosi al riguardo. Red Hat,
ad esempio, ha dichiarato di voler arrivare entro il 2009 a ottenere il 60 per cento del fatturato dal mercato Asiatico e dalle nazioni del Pacifico e intende aumentare il numero di dipendenti
nell’area di circa mille unità. L’opportunità più interessante per Red Hat è il bisogno di molte
aziende e Pubbliche Amministrazioni della zona di migrare da sistemi Unix obsoleti e troppo
costosi a soluzioni più economiche ma altrettanto valide: i clienti per questo tipo di accordi sono soprattutto nei settori finanziario e delle telecomunicazioni. Dal canto suo Novell ha piani
altrettanto importanti ma diversi, e intende fare di Suse Linux il desktop preferito dalle Pubbliche Amministrazioni asiatiche, soprattutto in China, Giappone, Thailandia e India, dove ha
firmato un contratto per 2000 server e 40000 desktop con lo stato del Tamil Nadu.
Etichette Rfid: meglio Open Source
R
fdump (www.rf-dump.org) è un programma Open Source con varie interfacce per leggere,
copiare o modificare i dati (tag) contenuti nelle etichette Rfid (Radio Frequency Identification) oggi aggiunte agli articoli più disparati. L’interfaccia grafica, che gira anche su Windows, è
basata sulle librerie Gtk, le stesse usate per l’ambiente desktop Gnome. Esiste anche una versione live su Cd-Rom (www.rfdump.org/live.shtml), che gira su Windows grazie a VmWare, per
provare Rfdump senza installare alcunché nel proprio computer. Sulla linea di comando Rfdump
è disponibile sotto forma di script Perl, compatibile anche con diversi Pda che supportano Linux. Da novembre 2007 Rfdump ha aggiunto o migliorato il supporto per vari formati standard
in questo campo: la lista dell’hardware già compatibile si trova su www.rfdump.org/hw.shtml.
Studiare e suonare musica senza interruzioni con VirtMus
I
tradizionali leggii per spartiti musicali non riescono a sostenere più
di un album o a mostrarne più di due pagine alla volta. Questo
semplice fatto è una notevole seccatura durante concerti ed esercitazioni, in quanto il musicista deve spesso staccare le mani dallo strumento per voltare pagina, rischiando interruzioni ed errori. La soluzione Open Source a questo problema è VirtMus
(http://virtmus.com/). Questo programma per Linux, Mac OS e Win-
dows mostra sullo schermo di un computer le pagine dello spartito
che si stanno suonando e soprattutto permette di cambiarle senza distrarsi tramite mouse, tastiera o pedaliera con interfaccia Usb. Gli
spartiti possono essere importati nel programma da scanner, fotografie digitali o file Pdf e raccolti in collezioni o Play List. La versione 1.01
di VirtMus è dotata anche di varie animazioni per passare da una pagina all’altra.
304
PC Professionale - Dicembre 2007