Compilare PVM su Mac OS X

PVM sta per Parallel Virtual Machine; si tratta di un framework open source per la realizzazione ed esecuzione di applicazioni distribuite su un insieme di macchine [eventualmente] eterogenee interconnesse mediante una rete.

Il software è distribuito come archivio di sorgenti in formato compresso .tar.gz e può essere scaricato a partire da questa pagina: http://www.netlib.org/pvm3/index.html

Ma veniamo alla compilazione sul nostro sistema. Se installiamo su una distribuzione GNU/Linux, il comando make impartito dalla directory pvm3, creata in seguito all’estrazione del pacchetto, non presenta alcun intoppo. E’ però necessario ricordarsi di settare la variabile di ambiente PVM_ROOT al valore corretto, ad esempio col comando:

export PVM_ROOT=`pwd`

impartito dalla suddetta directory (da qui in poi, i path relativi sono da considerarsi rispetto a tale directory).

Su un sistema Mac OS X(*), invece, la compilazione restituisce il seguente errore:

../../src/pmsg.c:785: error: static declaration of ‘xdr_float’ follows non-static declaration

/usr/include/rpc/xdr.h:332: error: previous declaration of ‘xdr_float’ was here

../../src/pmsg.c:794: error: static declaration of ‘xdr_double’ follows non-static declaration

/usr/include/rpc/xdr.h:333: error: previous declaration of ‘xdr_double’ was here

Evidentemente ci sono problemi con la definizione di due funzioni nel file src/pmsg.c, che risultano già dichiarate nel file /usr/include/rpc/xdr.h. Come si può osservare nel file src/pmsg.c, però, tale definizione è inserita in un blocco condizionale che viene processato solo se è definita la macro FAKEXDRFLOAT; ciò significa che, se otteniamo quell’errore durante la compilazione su Mac OS X, per qualche motivo tale macro risulta effettivamente definita. La soluzione più intuitiva, quindi, appare quella di fare in modo che la macro FAKEXDRFLOAT non venga definita. Un workaround “casareccio” che risolve il problema è quello di editare il file conf/DARWIN.def cancellando dalla riga 4 il flag -DFAKEXDRFLOAT. Fatto ciò, impartendo nuovamente il comando make, la compilazione va a buon fine.

Attenzione: non è detto che questo modo di procedere sia quello più corretto e non induca errori inaspettati in fase di esecuzione del runtime di PVM o delle applicazioni che dovranno girare su di esso. Se non si vogliono correre rischi, è preferibile installare questo software mediante MacPorts, anche se attualmente sono fermi alla versione 3.4.5 quando la più recente è la 3.4.6.

Ciao

(*) Testato su Mac OS X 10.4.11 (Tiger) con XCode 2.0 e su Mac OS X 10.5.6 (Leopard) con XCode 3.0.

Il mio nuovo pc fisso :-)

Dopo mesi di dubbi ed incertezze ho finalmente acquistato un nuovo pc fisso. Ne avevo già un paio, di cui uno acquistato usato un paio di anni fa alla modica cifra di 100 euro (monitor 17” incluso), ma entrambi erano un po’ vecchiotti, avendo rispettivamente otto e nove anni, e non più in grado di far girare decentemente alcune applicazioni che uso abitualmente (in primo luogo gli IDE Eclipse e Netbeans).
Per questo motivo, ma anche per la curiosità e la voglia di assemblarmi un pc da zero con le mie mani, ho deciso di fare questa spesa.

Questo è quello che ho comprato:

• Mainboard ASRock 4Core1600-D800
• Processore Intel Pentium Dual-Core E2180 (2GHz, 1MB L2 cache, 800 MHz FSB)
• RAM: un modulo da 2 GB PC-6400 DDR2
• Hard Disk Seagate 160GB Sata-II
• Case ATX
• Tastiera PS2

Il monitor lcd, la scheda audio 5.1, l’unità ottica ed il mouse ce li avevo già.
Totale della spesa: circa 230 euro (i.i.) presso il mio negozio di fiducia (su internet avrei risparmiato qualcosina, ma ho preferito così).
Perché ho scelto proprio quella scheda madre? Perché è economica ed ha una scheda grafica Intel integrata (le Intel funzionano benissimo con Linux e non volevo spendere altri soldi); ha comunque uno slot PCI-Express 16x per installare una scheda grafica più performante.

Assemblato il tutto in poche ore, nonostante non avessi mai montato un processore con soket 775, è stato il momento di installare il sistema operativo.
Per verificare che tutto funzionasse a dovere, ho installato al volo una Ubuntu 8.04 e mi sono accorto che la scheda di rete Ethernet integrata (Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)) faceva un po’ di storie; il resto non dava alcun problema e l’accelerazione 3D funzionava “out of the box”.
A quel punto ho provveduto ad installare Debian Lenny usando una immagine netinst recentissima (28 settembre) ma, manco a dirlo, la scheda di rete non voleva saperne di funzionare. Per ovviare al problema senza perdere troppo tempo, ho montato un’altra scheda di rete Ethernet PCI e sono andato avanti. Terminata l’installazione e la configurazione del sistema, ho collegato il cavo alla scheda di rete integrata e, miracolosamente, questa ha preso a funzionare. Ho così potuto rimuovere la scheda PCI per rimetterla al pc dal quale la avevo presa.

Ora ho una fiammante Debian Lenny (testing) che funziona alla perfezione; il sistema nel suo complesso è stabile ed estremamente reattivo: tutte le applicazioni si avviano in pochi istanti e funzionano senza rallentamenti di sorta. Una cosa insolita per uno che, come me, lavorava ancora su un Pentium III a 733 MHz

Ma che fine hanno fatto i due vecchi pc? Quello “più potente” (Athlon 1100MHz, 1 GB di RAM, GPU Nvidia FX5200GO 128MB, HD ATA 160GB) l’ho destinato ad ospitare Windows XP Professional SP3 (tanto per avere almeno un sistema Micro$oft funzionante) e una distribuzione Linux in dual-boot (devo ancora decidere quale); l’altro (Pentium III, 384MB di RAM, no GPU, HD ATA 160GB) mi farà da file server, web server, data-base server, subversion server, quellochemipare server utilizzando probabilmente una distribuzione Debian, Slackware o Ubuntu server.

Eh, si… sono soddisfazioni

Ciao da Gica

Suspend to ram: si fa così

In questo post descrivo brevemente come far funzionare correttamente il suspend to ram su un portatile Acer Extensa 5620 con Debian Lenny. Diversamente da quanto scritto nel post precedente, le opzioni per il comando s2ram vanno messe nei file di configurazione di pm-utils e non di hibernate. In realtà i pacchetti hibernate, acpi, acpi-support e acpi-support-base possono essere eliminati. Quello che serve sono i pacchetti acipid e pm-utils; inoltre è consigliabile sostituire Klaptop con Kpowersave.

Ricordo che, siccome questo portatile ha una scheda grafica Intel (Intel Corporation Mobile GM965/GM960), le corrette opzioni per il comando s2ram sono “-f -a3” (oppure “-f -p -m“), come descritto qui, e che prima della sospensione è necessario scaricare il modulo psmouse dal kernel.

Quindi per ottenere il corretto funzionamento della sospensione su ram è sufficiente creare il file /etc/pm/config.d/defaults con il seguente contenuto:

SLEEP_MODULE=”uswsusp”

SUSPEND_MODULES=”psmouse”

S2RAM_OPTS=”-f -a3″

A questo punto potete avviare la sospensione su disco invocando, da utente root, il comando pm-suspend oppure direttamente dall’applet Kpowersave dopo aver inserito il vostro utente nel gruppo powerdev.

Se in seguito al resume (sia da ram che da disco) il vostro touchpad dovesse comportarsi in maniera anomala, è sufficiente passare ad una console testuale e poi tornare alla sessione grafica premendo, rispettivamente, le combinazioni di tasti CTRL-ALT-F1 e poi CTRL-ALT-F7.

Da quanto ho potuto osservare, il resume da disco funziona nel 100% dei casi (purché non usiate usplash o cose simili), mentre con il resume da ram di tanto in tanto si verificano dei freeze ancora inspiegati. Speriamo di venirne a capo il prima possibile.

Ciao da Gica

Suspend to RAM su Extensa 5620 con Debian Lenny (testing)

Avviso: le istruzioni riportate in questo how-to non sembrano produrre risultati stabili. Per maggiore sicurezza è consigliabile usare il suspend to disk.

Sul mio Acer Extensa 5620 sono tornato definitivamente alla versione 32 bit di Debian Lenny (ancora in fase testing). Diversamente da Ubuntu e Fedora, qui c’è qualcosina in più da fare per far funzionare alcuni dispositivi e caratteristiche. In particolare ho dovuto sudare non poco per riuscire a far funzionare a dovere il Suspend to RAM, cioè quella funzione che mette il computer in uno stato di risparmio energetico senza spegnerlo, usando soltanto l’energia necessaria a conservare il contenuto della memoria. Questo è l’equivalente dello stato di STOP dei Macintosh e permette di avere tempi di ripristino molto brevi: due o tre secondi. In realtà il notebook entrava correttamente nello stato di sospensione ma al “resume”, dopo una sorta di reset dell’alimentazione, esso rimaneva bloccato, col monitor spento e con la ventola in funzione. A quel punto non c’era altro da fare che resettare brutalmente il computer, perdendo ovviamente la sessione salvata in memoria.

Per risolvere ho iniziato a studiare un po’ la documentazione del comando s2ram e, successivamente, questa pagina del progetto openSUSE, dalle quali ho ricavato molte informazioni utili. Effettuando i primi test, ho notato che la mia piattaforma non era tra quelle supportate:

debian:~# s2ram -n
Machine unknown
This machine can be identified by:
sys_vendor = “Acer “
sys_product = “Extensa 5620 “
sys_version = “0100 “
bios_version = “V1.16 “
See http://suspend.sf.net/s2ram-support.html for details.

If you report a problem, please include the complete output above.

Di conseguenza, non mi rimaneva che avviare il sistema con una shell di init e andare per tentativi.

Quasi immediatamente ho notato che con il comando s2ram -f -a3 il suspend ed il successivo resume andavano sempre a buon fine (come osservato nel caso di schede grafiche Intel). Ho quindi riprovato quel comando in una normale sessione grafica, ma lì il risultato era negativo: ancora un freeze del sistema e conseguente reset. Un po’ scoraggiato ma tutt’altro che rassegnato, ho ripreso a cercare informazioni su internet, questa volta riguardanti direttamente il mio tipo di portatile, fino a trovare questo sintetico ma utilissimo wiki in cui si osserva che per far funzionare il suspend to ram sull’Extensa 5620 è prima necessario scaricare dal kernel il modulo psmouse (il driver per i mouse PS/2). In questo modo ho osservato che effettivamente la cosa funzionava; non restava altro che automatizzare il tutto, modificando i file di configurazione dei servizi di sospensione/ibernazione affinché bastasse un click sull’apposita voce del menu di KLaptop per mandare il notebook in stop. Ancora una volta mi sono tornate utilissime le pagine di manuale del sistema, in particolare quella del file hibernate.conf (digitate man hibernate.conf da terminale), ed i commenti presenti nei file della directory /etc/hibernate/. Per ottenere il comportamento desiderato, ho inserito le seguenti opzioni in testa al file /etc/hibernate/ram.conf:

USuspendRamForce yes # per l’opzione -f a s2ram

USuspendRamAcpiSleep 3 # per l’opzione -a3 a s2ram

UnloadModules psmouse # per scaricare psmouse prima della sospensione

LoadModules auto # per ricaricare al resume i moduli precedentemente scaricati

Fatto questo, la funzione di sospensione su ram sembra funzionare perfettamente!

Ciao da Gica

Update: le stesse opzioni che ho citato nell’articolo sono già presenti nel file /etc/hibernate/ususpend-ram.conf; quindi, per attivarle, basta decommentarle

Update2: ho reinstallato il sistema da zero, e pur reimpostando le suddette opzioni il suspend to ram non funziona come si deve. Forse dimentico qualcosa, o forse c’è qualcosa che non va col mio portatile

Flashplayer plugin su Debian x86-64 testing (Lenny)

Sul mio Acer Extensa 5620 ho appena installato Debian Lenny (ancora in fase testing) nella versione a 64 bit. Tra le prime cose che ho voluto fare c’è l’installazione del plugin flashplayer per Firefox. Non essendoci una versione a 64 bit del suddetto plugin, ho scaricato la versione a 32 bit e poi ho cercato di installarla mediante nspluginwrapper (installato via apt). Il problema è che, seguendo le istruzioni trovate sul sito, ottenevo sempre l’errore

*** NSPlugin Viewer *** ERROR: libflashplayer.so: cannot open shared object file: No such file or directory
nspluginwrapper: no appropriate viewer found for libflashplayer.so

Allora, cercando in rete, ho trovato questo post, un po’ vecchiotto, che suggeriva di aggiungere un link simbolico all’eseguibile npviewer affinché comparisse nel proprio search path. Anche questo tentativo, però, non ha dato alcun risultato.

Quasi demoralizzato e deluso anche dal fatto che il plugin “libero” non funziona a dovere, ero quasi tentato di abbandonare l’impresa, se non che, ancora cercando con Google, mi sono accorto che la soluzione era più vicina di quanto potessi pensare: era nascosta in una guida del Debianclan.

La guida in questione ha subito delle modifiche in seguito all’integrazione del plugin “non-free” nei repository Debian, ma poiché io quel plugin preconfezionato non riesco proprio a trovarlo (l’avranno nuovamente rimosso?) ho seguito la via “manuale” procedendo nel seguente modo:

1. ho scaricato e scompattato il pacchetto .tar.gz del plugin flashplayer preso dal sito di Adobe
2. ho copiato il file libflashplayer.so nella directory /usr/lib64/mozilla/plugins/ (bisogna essere root)
3. ho invocato il comando npconfig, sempre come root, nel seguente modo (su un’unica riga, mi raccomando):
   /usr/lib/nspluginwrapper/x86_64/linux/npconfig -i /usr/lib64/mozilla/plugins/libflashplayer.so
4. Fine

Probabilmente questo non è il modo migliore, né quello più pulito, però ha funzionato.

Nei prossimi giorni proverò ad installare allo stesso modo anche il plugin java per il browser.

Update: come suggerito da x4b, le istruzioni per installare correttamente il plugin flashplayer su Debian testing (per amd64 e i386) si trovano in questo wiki Debian, dove si spiega che va installato il pacchetto flashplugin-nonfree del ramo unstable della distribuzione. Vi segnalo anche la guida dello stesso x4b.

Ciao da Gica

Java: classpath malefico

Quanti di voi, alle prime armi con Java senza utilizzare alcun IDE, non hanno mai avuto qualche problema in fase di compilazione di un programma facente uso di package “artigianali”, cioè creati da voi stessi? Non molti, suppongo.
In questo post spiego brevemente l’utilizzo dell’opzione classpath da passare sia al compilatore che all’interprete Java. Le stesse considerazioni, ovvero gli stessi valori, si applicano alla variabile di ambiente CLASSPATH, se preferite usare quella.

Supponiamo di avere tutti i nostri package personali nella directory /programmazione/java/mypackages/. Come ben sappiamo, i nomi dei package dovranno essere tali da rispecchiare la gerarchia di sottodirectory in cui sono memorizzati. Ad esempio le classi appartenenti al package di nome foo.bar (che conterranno quindi la direttiva package foo.bar;) dovranno essere memorizzate nella sottodirectory bar della directory foo; per come ci siamo organizzati noi, la directory foo sarà a sua volta conenuta in /programmazione/java/mypackages/. Se le classi in questione non contengono riferimenti ad altri package locali, la loro compilazione filerà liscia senza passare alcuna opzione al compilatore.

Dopo averle compilate, supponiamo di scrivere l’applicazione Test.java che fa uso delle classi del package foo.bar (e conterrà quindi la direttiva import foo.bar.*;) e di salvarla nella directory /programmazione/java; affinché la compilazione dell’applicazione abbia successo, è necessario comunicare al compilatore in quale directory reperire il package. Quindi il comando di compilazione sarà di questo tipo:

javac -classpath /programmazione/java/mypackages/ Test.java

Ovviamente, se includiamo anche package memorizzati in altre directory, dovremo cambiare l’opzione classpath di conseguenza, aggiungendo anche gli altri path separati dal carattere : (duepunti).

La cosa curiosa è che l’opzione classpath sarà necessaria anche per l’esecuzione dell’applicazione Test, ma con una leggera modifica: dovremo aggiungere al classpath anche la directory corrente. Il comando per eseguire l’applicazione test, allora, sarà:

java -classpath .:/programmazione/java/mypackages Test

Per il momento è tutto. Man mano che andrò avanti con lo studio di questo assurdo linguaggio, pubblicherò le difficoltà incontrate e le soluzioni applicate.

Ciao da Gica

PyCon2

Il 9, 10 e 11 maggio, a Firenze, si terrà il PyCon2, la seconda conferenza italiana dedicata al linguaggio di programmazione Python. Nella giornata di apertura è previsto un keynote tenuto da Richard Stallman.
Tra gli sponsor, oltre a Google, Skype ed altri, segnalo Truelite, la società per la quale lavora il buon Simone Piccardi, cioè l’autore di GaPiL, il libro sulle glibc che sarà stato senz’altro utile a coloro che hanno dovuto realizzare la tesina su Unix per l’esame di sistemi operativi presso le facoltà di ingegneria.

Tra gli organizzatori e relatori della conferenza non posso non segnalare tekNico, un vecchio amico del Ciociaria Linux User Group.

Se tutto va bene, cioè se mi andranno bene i prossimi tre esami, potrei essere presente alla conferenza; sarà la volta buona che mi deciderò a studiare Python seriamente

Ringrazio OSSblog, senza il quale non mi sarei ricordato di andare a rivedere il sito del PyCon.

Ciao da Gica

Acer Extensa 5620 – cuffie

Recentemente ho installato Fedora 8 su un portatile Acer Extensa 5620. La maggior parte dell’hardware ha funzionato subito, senza necessità di configurazioni particolari. L’unico fastidioso problema l’ho riscontrato sul sistema audio (Intel HD audio controller 82801H): volume molto basso e cuffie malfunzionanti. In particolare, all’inserimento del jack degli auricolari, non si verificava l’esclusione automatica degli altoparlanti integrati. La soluzione del problema è relativamente semplice: basta modificare il file /etc/modprobe.conf aggiungendo l’opzione

model=acer

alla fine della riga contenente quanto segue:

options snd-hda-intel index=0

Dopo la modifica, ricordatevi di riavviare il computer.

Sul mio sistema, l’intero file /etc/modprobe.conf è il seguente:

alias eth0 tg3
alias scsi_hostadapter libata
alias scsi_hostadapter1 ata_piix
alias scsi_hostadapter2 ahci
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0 model=acer

Lo stesso problema è stato riscontrato da utenti Ubuntu, ed è proprio grazie a loro che ho risolto anche su Fedora.

Altre soluzioni per lo stesso hardware audio ma su portatili differenti le trovate su questa pagina (le istruzioni si riferiscono alla distribuzione Ubuntu Gutsy Gibbon).

Ciao da Gica

Sun JDK 6 su Fedora

Ciao! Ultimamente non ho avuto molto tempo per scrivere su questo blog, comunque voglio segnalarvi un ottimo how-to che mi è stato utile per installare il Sun JDK 6 (update 4) su Fedora 8; l’how-to è in italiano e lo trovate a questo indirizzo.

La guida descrive l’installazione dell’update 3, ma le istruzioni valgono anche per l’update 4, avendo l’accortezza di scaricare la giusta versione del pacchetto java-1.6.0-sun-compat.

Ciao da Gica

Java-Package: un modo migliore di installarlo

In precedenza ho scritto un post sulla pacchettizzazione ed installazione della versione 6 del Java Software Developement Kit (jdk6) su Debian Etch. Tale operazione richiedeva la presenza sul sistema di una versione del pacchetto java-package più aggiornata rispetto a quella presente nei repository di Etch. Le mie istruzioni prevedevano il download e l’installazione manuale di una versione aggiornata del pacchetto, prendendola dai repository del ramo testing di Debian (Lenny). Una maniera migliore di ottenere lo stesso risultato consiste nel fare il backport del pacchetto java-package da Lenny ad Etch, usando il comando build di apt-get.

Per prima cosa è necessario modificare il file /etc/apt/sources.list, inserendo come repository dei sorgenti quelli di Lenny al posto di quelli di Etch; quindi al posto di

deb-src http://ftp.at.debian.org/debian/ etch main contrib non-free

metterete

deb-src http://ftp.at.debian.org/debian/ testing main contrib non-free

(ovviamente sostituendo “ftp.at.debian.org” con l’indirizzo del vostro server preferito).
Quindi, dopo aver aggiornato la lista dei pacchetti con

apt-get update

ed esservi spostati in una directory (a vostro piacimento) dedicata alla compilazione dei pacchetti, potete dare i comandi:

• apt-get build-dep java-package
• apt-get source --compile java-package

ottenendo nella directory corrente il pacchetto java-package aggiornato pronto per essere installato. Infatti il primo dei precedenti comandi si occupa di installare sul vostro sistema le dipendenze necessarie alla compilazione, mentre il secondo scarica i sorgenti di java-package, li compila e produce il relativo pacchetto deb.

Dopo l’installazione del suddetto pacchetto, col solito

dpkg -i java-package<versione>.deb

potrete provvedere alla pacchettizzazione della versione 6 del JDK secondo le modalità illustrate nel mio precedente post o nell’ottimo howto di debianizzati.org.

Buon lavoro

Gica