Caio's BlogA life in technique

Da qualche giorno ho acquistato un irresistibile giocattolino, una di quelle meraviglie della tecnica impensabili fino a pochi anni fa, che recentemente sta conquistando enormi fette di mercato nel settore dei pc: uno spettacolo di portabilità ed efficienza, ovvero ciò che per il campo di utilizzo viene comunemente definito Netbook.

Dopo svariate ricerche ho trovato nell’Acer Aspire One D150 un ottimo compromesso tra prezzo e dotazione, anche se praticamente fino ad ora tutti i netbook se la giocano principalmente sull’hard disk (SSD vs SATA) e sulla batteria (3 celle vs 6 celle), meno sul quantitativo di RAM (da 512MB a 2GB) installata e poco sullo schermo (8.9″ vs 10″ vs 11″), visto che la piattaforma su cui viene distribuito l’Atom sui netbook è solo quella dell’intel e la scelta tra 945 o GN40 di certo non fa una gran differenza.

Sicuramente si vedranno enormi evoluzioni a breve visto che il segmento è appena nato, e visto che su piattaforme fisse Nvidia ha già iniziato a distribuire soluzioni di un certo livello che offrono un pool di connessioni di I/O (HDMI, eSata, LAN Gigabit, ecc…) e un comparto grafico di tutto rispetto e ben superiori rispetto a ciò che si può trovare sulla maggioranza dei netpc attualmente sugli scaffali.

Il D150 che ho tra le mani monta un TOSHIBA MK1655GSX, disco assolutamente silenzioso e discretamente prestante, con 8MB di cache e rotazione a 5400rpm come la maggioranza dei dischi da 2,5″.

Per quanto mi riguarda il netbook è uno strumento dedicato principalmente a 2 compiti:

• accesso ad internet con maggior comodità rispetto a quanto si possa fare da un PDA quando il portatile da 4Kg è troppo scomodo da poter essere portato appresso
• gestione e condivisione di file all’interno della rete locale¹

Dal momento che lo sfruttamento delle potenzialità del dispositivo² è una delle caratteristiche più importanti per questa tipologia di utilizzo, ho voluto effettuare alcuni test di trasferimento dati per tastare con mano la qualità di gestione dei dischi dai due sistemi operativi principali che vi si possono installare in questo momento.

Dati dei sistemi utilizzati nei test

Sistema operativo

1. Netbook 1: Windows 7 Ultimate X86 patchato all’11/09/2009
2. Netbook 2: Ubuntu 9.04 con Xfce, kernel 2.6.28-15-generic
3. PC: Windows Vista 64bit SP2

PC

1. Acer Aspire D150 160GB hard disk, 1GB ram
2. Intel Core2duo E4300@3.1GHz, 6GB ram, Asus P5N-E SLI

Hard disk

1. Netbook: Toshiba MK1655GSX – Filesystem NTFS su Windows 7 ed EXT3 su Linux
2. PC: HD Seagate Barracuda 500Gb SATA-II NCQ 7200 RPM 32Mb ST350032 – Filesystem NTFS
3. USB: WD Elements 500GB – Filesystem NTFS

Network

1. Netbook: Ethernet Attansic L1e 10/100MB
2. PC: Ethernet Nvidia Gigabit controller
3. Switch: Cisco Gigabit 8 porte

Tipologie di test

1. LOCAL READ: lettura da disco locale (1) scrittura su USB (3)
2. LOCAL WRITE: scrittura su disco locale (1) lettura da USB (3)
3. NETWORK READ: lettura da disco locale (1) e scrittura su PC remoto(2)
4. NETWORK WRITE: scrittura su  disco locale (1) e lettura da PC remoto(2)

Metodologia

1. Per le operazioni su Windows 7 si è utilizzato explorer da interfaccia grafica, e i tempi misurati sono stati rilevati in concomitanza con l’apertura del popup della copia e la chiusura dello stesso³
2. Per le operazioni su Linux si è utilizzata la shell e i tempi sono stati rilevati dal comando time. Il file system remoto è stato montato utilizzando le utility del pacchetto smbfs.

RISULTATI⁴

Windows 7

1. File da 4.555.188KB copiato in 529s ==> 8,40MB/s
2. File da 4.694.939.550B copiato in 163s ==> 27,46MB/s
3. File da 992.837.632KB copiato in 83s ==> 11,40MB/s
4. File da 992.837.632KB copiato in 84s ==> 11,27MB/s

Linux

1. File da 4.555.188KB copiato in 10m 44.292s ==> 6.90MB
2. File da 4.555.188KB copiato in 1m 28.830s ==> 18MB/s
3. File da 1.463.969.792B copiato in 3m 47.732 s ==> 6,15MB/s
4. File da 1.463.969.792B copiato in 4m 7.730s ==> 5,65MB/s

Test 3 su Windows 7: trasferimento dal disco locale al PC in rete

Test 2 su Windows 7: trasferimento dal disco USB al disco locale

I risultati parlano da se, avevo avuto questo sentore verificando la relativa lentezza nella velocità di trasferimento osservata sulla Ubuntu, che personalmente ritengo una distribuzione eccezionale vista la semplicità di utilizzo e perfetta su questi netbook: è leggera e veloce, tutto l’hardware viene riconosciuto durante l’installazione e, sorpresa delle sorprese, finalmente  è possibile condividere la connessione al pc tramite il PDA con windows mobile usandolo come modem UMTS senza ricompilare nulla, visto che il modulo rndis è già perfettamente integrato nel kernel.

Ma a parte le considerazioni sul sistema operativo, i numeri non sono contestabili e i vantaggi che arrivano al 100% nei trasferimenti di rete da parte di Windows 7 decretano una gestione dell’hardware pesantemente migliore per quanto riguarda il comparto disco-rete.

1. determinante l’assorbimento di energia elettrica estremamente ridotto [↩]
2. e in particolare della velocità di trasferimento dati [↩]
3. certo non è un gran metodo ma funziona e se si considera uno scarto del 2-3% può essere ritenuto affidabile [↩]
4. note per la lettura: i numeri si riferiscono alla tipologia di test, quindi il test 1 è quello di LOCAL READ, ecc.. [↩]

Con un progetto non proprio aggiornatissimo (ma forse solo perchè non ce n’è bisogno) YaReg continua a funzionare alla grande, senza problemi di sorta, anche sulle versioni di Vista a 64bit servicepaccate, consentendoci di leggere velocemente i file contenuti nelle partizioni formattate in ReiserFS senza nemmeno la necessità di installarsi sul pc (eseguibile al volo da qualunque dispositivo). Testato e funzionante.

Ovviamente è tutto scaricabile dal sito ufficiale…

make[2]: *** [/tmp/vmware-config0/vmnet-only/userif.o] Error 1
make[1]: *** [_module_/tmp/vmware-config0/vmnet-only] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.22′
make: *** [vmnet.ko] Error 2
make: Leaving directory `/tmp/vmware-config0/vmnet-only’
Unable to build the vmnet module.

For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".

Execution aborted.

Automount tips and tricks

In questi giorni mi è venuta voglia di automount (evitiamo battutacce ) per cui ho deciso di aggiungere questa immancabile funzionalità alla mia Gentoo box.

Ero all’oscuro del fatto che KDE potesse gestire autonomamente la situazione, senza l’ausilio di software esterni come ivman o gnome-volume-manager, ma con il solo aiuto dei servizi dbus e hald.

Dopo aver installato le versioni più recenti di entrambi i servizi, e per compatibilità con KDE, dbus-qt3, è possibile abilitare l’opzione dal control center di KDE sotto Pheriperals->Storage Media->Advanced.

E’ possibile però che pur facendo queste 2 semplici cose non funzioni nulla e si vaghi in balia di aiuto senza sapere dove andare a parare.

Quello che mi è capitato è che, pur essendo installato tutto correttamente (hal v.0.5.9.1-r2 e dbus v.1.0.2-r2) nulla funzionasse inspiegabilmente. Il problema era che, nonostante hal dicesse di essersi avviato:

Painkiller ~ # /etc/init.d/hald start
 * Starting Hardware Abstraction Layer daemon …

in realtà non lo faceva e ovviamente tutto il resto non poteva funzionare.
(Ci si può acccorgere del fatto che hal non parta semplicemente sbirciando tra i processi attivi).

Il problema sembrava essere legato al fatto che nel mio kernel l’opzione CONFIG_INOTIFY (che si trova in File systems—>Inotify file change notification support  e Inotify support for userspace)  :

Painkiller ~ # cat /usr/src/linux/.config|grep CONFIG_INOTIFY_USER
CONFIG_INOTIFY_USER is not set

non era attiva e quindi tutto il sistema di notifiche sull’inserimento di nuovi dispositivi mancava del supporto necessario.
A questo punto è bastata una ricompilata del nocciolo con entrambe le opzioni attive e dal riavvio successivo come per magia tutti i dispositivi inseriti a caldo vengono riconosciuti automaticamente.

Se a questo punto poi sentite l’esigenza di montare delle partizioni utilizzando dei tool particolari, come ad esempio ntfs-3g per le partizioni in NTFS in modo che oltre a leggerle vi possiate anche scrivere, è sufficente (almeno per la versione attuale) aggiungere il file /etc/hal/fdi/policy/10-ntfs-policy.fdi con queste istruzioni:

<?xml version="1.0" encoding="UTF-8"?><deviceinfo version="0.2">   <device>       <match key="volume.fstype" string="ntfs">           <match key="@block.storage_device:storage.hotpluggable" bool="true">               <merge key="volume.fstype" type="string">ntfs-3g</merge>               <merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge>               <append key="volume.mount.valid_options" type="strlist">locale=</append>           </match>       </match>   </device></deviceinfo>

come spiegato nell’ottimo wiki su Gentoo HOWTO NTFS write with ntfs-3g.

Virtual Box

Qualche tempo fa un amico mi ha parlato molto bene di questo “nuovo” software di virtualizzazione, l’equivalente Open Source della classica Vmware per intenderci.

Preso dalla curiosità ho voluto provarlo appena il tempo me l’ha concesso, e devo dire di esserne rimasto piacevolmente sorpreso.

Infatti VirtualBox funziona alla perfezione sia su Linux che, ovviamente, su Windows, e secondo voci di corridoio (leggi ufficiali) anche su Mac.
Tutte le features che Vmware offriva sono pienamente supportate, rete, dispositivi USB e udite udite anche l’audio funzionano alla perfezione (per qualche strano motivo avevo sempre avuto problemi con Alsa su Linux), senza difficoltà ne problemi di sorta.

Ovviamente anche le “addictions” che forniscono miglioramenti alla macchina virtuale, come i driver video con supporto ad alte risoluzioni, sono disponibili, installabili a parte come in Vmware.

Per quanto riguarda Gentoo è necessario smascherare la versione unstable del pacchetto e se vogliamo le addictions ricompilare il tutto utilizzando la USE flag “additions” appunto, e siamo pronti a virtualizzare in modo veloce simple & easy

Finalmente…

BUONE NOTIZIE

Ho appena finito di installare il driver nativo per i filesystem Ext2 e Ext3 (journaling non supportato) sotto Windows Vista.

Nonostante sembra non funzionare alla prima installazione (dice che la versione non supporta il sistema operativo in uso) è sufficente lanciare l’eseguibile come Administrator e rilanciarlo più volte dicendogli di fregarsene della compatibilità, autorizzare l’installazione del driver, selezionare la partizione Ext2 o Ext3 con la relativa lettera da assegnare alla partizione e, ovviamente (che ve lo dico a fà?) , riavviare.

E come per magia dal boot successivo potrete accedere in lettura e scrittura alle vostre partizioni Ext senza problemi anche dal vostro W. Vista *

Il driver è disponibile alla pagina del progetto ufficiale qui.

*Testato personalmente su Vista Business N Edition con partizione Ext3

Documentazione software

Doxygen è un potentissimo strumento, in grado di generare documentazione dettagliata di qualunque progetto software, a partire dal codice sorgente anche non commentato di moltissimi linguaggi di programmazione (ufficialmente supporta C#, C++,C, Java, ma probabilmente si può ottenere ottima documentazione anche con altri linguaggi).

FGLRX

Da qualche tempo non installavo i driver Ati ufficiali sulla mia debian, tra le tante cause la mancanza della necessità di farlo (il driver ati fornito come modulo del kernel funziona benissimo) e l’assenza di supporto ufficiale regolarmente aggiornabile da apt, a differenza di quanto invece avviene da tempo con Nvidia.

Utilizzando la versione Sid di Debian (Unstable) che rilascia pacchetti più nuovi con un’elevata frequenza, avevo avuto di recente la spiacevole sorpresa di non riuscire a ricompilare i driver, perchè il range di versioni di Xorg supportate non includeva la più recente versione 7 utilizzata da Debian.
Essendo passato del tempo però, ed avendoci messo un po gli sviluppatori di Ati a rilasciare i nuovi driver ufficiali per Linux, mi ero illuso di poter trovare una soluzione pulita facilmente installabile che potesse filare liscia dall’inizio alla fine.

lanciare l’installazione da shell:

e subito mi accorgo dell’infondatezza di tutte le mie speranze, i driver ati tanto per cambiare danno problemi e falliscono l’installazione durante la compilazione del modulo.
Andando a leggere l’output questo è l’errore ritornato:

Questa volta non mi do per vinto, e vado alla ricerca di una soluzione.
Cerca e ricerca trovo qua e la qualche spiegazione (il forum slacky.it è stato essenziale), ma niente di organizzato e chiaro, per cui dopo aver risolto ho deciso di postare questo piccolo articolo in modo da riassumere i passaggi necessari a risolvere il tutto.

Dopo aver lanciato l’installazione (non da rpm) che è fallita, dovremmo trovare una directory in /lib/modules/fglrx/, contenente i files necessari al completamento.
A questo punto è necessario recarsi nella directory /lib/modules/fglrx/build_mod/ :

e dare 3 comandi che servono a sistemare i files "bacati":

Fatto questo possiamo lanciare la compilazione del modulo fglrx:

poi lo installiamo spostandoci nella directory padre:

e infine lo carichiamo:

e se necessario editiamo il file xorg.conf aggiungendo il nome del driver appena compilato da caricare all’avvio di X:

Fatto!
Riavviamo X e verifichiamo che i driver siano stati caricati correttamente:

Ora possiamo utilizzare i driver Ati ufficiali nonostante l’avversione degli sviluppatori nel fornirci un supporto funzionante!

Caratteri troppo piccoli in google earth