Intro
2008-10-25
Questo blog vuole essere una specie di “diario di bordo” per i miei esperimenti in materia di IT.
Quindi non sarà altro che una raccolta di appunti, su argomenti vari e più o meno approfonditi, utili principalmente a me stesso.
Inoltre userò lo stream of cosciousness.
Main banner by 2501sodapop
Comandare il puntatore con le dita?!
2008-11-16
Ispirato da questo video di Johnny Lee mi sono messo a giocherellare con l’idea di scrivere un driver che permetta di usare le dita per muovere il cursore del mouse.
Teoria
L’idea di baste è usare il wiimote come lettore della posizione delle dita, quindi posizionato davanti all’utilizzatore (magari sul monitor) e sistemare dei led ad infrarosso sulle dita dell’utilizzatore.
L’hardware richiesto è composto dal wiimote e da un esoterico intrico di fili e led che vanno sulla mano dell’utilizzatore. (Posterò un immagine quanto prima…)
Per quel che riguarda il software invece quello di cui ho bisogno sono principalmente due componenti:
- un driver per il wiimote a livello kernel.
Si deve occupare di leggere i dati dal wiimote e renderli disponibili al sistema tramite un device file (un file in /dev per intenderci..)
- un driver per il server X.
Deve leggere i dati dal device file, interpretarli e rigirare gli eventi appropriati al server X
Lo stato attuale dell’arte non fornisce nessuno di questi due componenti, quindi il mio lavoro parte da zero.
Per prima cosa mi sono occupato di scrivere un driver per il server X. Partendo da questa ottima guida e spulciando il codice di alcuni driver (mouse, evdev…) sono riuscito a realizzare un driver che legge da un file di dispositivo e muove il puntatore di conseguenza. C’è anche l’emulazione dei tasti del mouse, quindi rimpiazza completamente un mouse.
Per quanto riguarda il driver livello kernel non sono riuscito a mettere insieme neanche un proof of concept ma ho trovato una via alternativa e decisamente non elegante per poter comunque ottenere un risultato usabile.
Quello che al momento si può fare è usare le dita esattamente come un mouse e fare tutto quel che un mouse permette di fare. Sulla mano sono posti 3 led in corrispondenza di 3 dita e devono essere usati così: il led centrale comanda il puntatore, il led sinistro indica click sinistro e il led destro indica click destro. Per simulare un click bisogna tenere i led fuori dal “campo visivo” del wiimote (ad es. piegando il dito) e mostrarli solo quando si intende cliccare.
Pratica
Come si mettono insieme tutte ste cose e si fa funzionare il tutto?
Questa procedura comporta l’installazione di software in fase di sviluppo ed è altamente sconsigliato eseguirla su un sistema su cui abitualmente si lavora.
Anzitutto serve la versione git di X. Per chi usa gentoo basta digitare
layman -a x11
autounmask x11-base/xorg-server-9999
emerge -av xorg-server
Per chi non usa gentoo un punto di partenza può essere questo.
Ora manca solo il mio software. Si trova qui e su gentoo può essere installato con
cd ~
git clone git://repo.or.cz/Fiinger.git
cd Fiinger
./autogen.sh –prefix=/usr
make
make install (da root o via sudo)
Il driver è installato, ma mancano ancora diverse cose: un device che piloti il driver e una entry in xorg.conf che indichi a X di utilizzare il nuovo driver. Partiamo dalle cose semplici, questa è la sezione relativa da aggiungere a xorg.conf
Section “InputDevice”
Identifier “Fiinger1″
Driver “fiinger”
Option “Device” “/dev/scullpipe”
EndSection
e non dimenticate di aggiungere anche
InputDevice “Fiinger1″ “CorePointer”
nella sezione ServerLayout.
Ci siamo quasi, manca solo un driver che gestisca il wiimote. Sfortunatamente non esiste e io non l’ho ancora scritto (e chissà se mai lo scriverò…) ma c’è un “metodo alternativo”. Nella directory Fiinger/apps/ c’è tutto il necessario, ovvero un driver “finto” che si comporta come una pipe e un programma utente che si collega al wiimote e rigira i dati letti al “driver-pipe”.
Il driver è preso dagli esempi del libro “linux device driver 3rd edition” e tutto il merito va agli autori del libro. Il programma utente è scritto da me e usa la libreria wiiuse per interfacciarsi col wiimote.
Vediamo come usare il tutto.
Per prima cosa bisogna compilare e caricare il modulo del driver:
cd ~/Fiinger/apps/kfiinger-module/
make
./scull_load (da root o via sudo)
A questo punto è necessario riavviare il server X in modo che il driver sia caricato e usabile. Potete verificare il successo tramite
xinput list –short
e dovreste vedere una riga del genere:
“Fiinger1″ id=2 [XExtensionPointer]
Ora non resta che lanciare il programma utente e testare l’effettivo funzionamento (o meno) del tutto.
cd ~/Fiinger/apps/wirft
make
./wirft <screen-x-resolution> <screen-y-resolution>
Naturalmente per testare il tutto serve avere un pc bluetooth-enabled, un wiimote, e il famoso “aggeggio”.
Se tutto è andato bene il mouse seguirà le dita!
Appena posso posterò anche un video che mostra il tutto in azione.
e2fsprogs-lib vs. ss & com_err
2008-11-08
Aggiornando lo stage3 con ~amd64 mi son trovato di fronte ad un blocking circolare tra:
e2fsprogs
e2fsprogs-lib
ss
com_err
[blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2)
Il problema è noto al bug track della gentoo e qui c’è la soluzione (un workaround veramente…)
Velocizzare il boot
2008-11-01
Inizialmente mi sono posto come obbiettivo di effetture il boot in meno di 30 secondi.
Ora, il sistema fa già il boot in 33 secondi, quindi i 30 secondi mi sembravano troppo vicini al tempo attuale. In realtà si è rivelato parecchio difficile abbassare questo tempo anche solo di un secondo.
Ma partiamo dall’inizio e vediamo che strumenti abbiamo a dispozione:
app-benchmarks/bootchart – demone che tiene traccia dell’utilizzo di cpu e disco al boot e genera un grafico. è quello che userò per misurare il cambiamento di prestazioni.
sys-apps/readahead-list – un demone che si occupa di leggere anticipatamente dei file dal disco in modo che i processi invocati successivamente si trovino i file necessari già in ram.
Installazione:
Entrambi i programmi sono in portage, quindi basterà un emerge -av per installarli sul sistema.
Configurazione:
Bootchart ha bisogna di essere impostato al boot del sistema come parametro di grub (o lilo), quindi bisogna editare il grub.conf o menu.lst a seconda della versione di grub; ecco un pezzo del mio grub.conf:
title=Gentoo-development-playground-bootcharted
root (hd0,7)
kernel /boot/playground-2.6.27-r1 root=/dev/sda8 vga=0×318 init=/sbin/bootchartd
Bisogna inoltre abilitare bootchart su /etc/conf.d/rc impostando:
# Set to “yes” if you want to benchmark system boot with bootchart.
# You’ll need to emerge the app-benchmarks/bootchart package for this to work.
RC_BOOTCHART=”yes”
Il file di configurazione vero e proprio di bootchart si trova invece su /etc/bootchartd.conf e permette di impostare dove verrà salvato il grafico generato e in che formato.
Readahead ha tre file di configurazione che si trovano in /etc/readahead-list/ e contengono semplicemente una lista di file da (pre)caricare al boot. Naturalmente questa lista di file non è fissa (sopratutto su gentoo) e dipende da quali servizi sono lanciati all’avvio del sistema (quelli nei runlevel boot e default). La configurazione quindi si riduce a creare questa lista. Quella data con il pacchetto è generica e sicuramente non la più adatta; ecco il risultato ottenuto sulla mia macchina con la configurazione originale:
OpenRC parallel boot with readahead-list
Naturalmente non sono soddisfatto di questo risultato, sta sopra i 30 secondi e poi non ho modificato nulla… Vediamo come posso migliorare i file di conf.
Sul bug track della gentoo ho trovato degli utili consigli in proposito. Il primo consiste nel cancellare dai file di config originali tutti i file che non esistono sul sistema in questione, perchè appartenenti a programmi non installati. Ecco come si fa:
a=$(<runlevel-boot ); echo “$a” |xargs ls -1 2>/dev/null > runlevel-boot
a=$(<runlevel-default ); echo “$a” |xargs ls -1 2>/dev/null > runlevel-default
a=$(<exec_sbin_rc ); echo “$a” |xargs ls -1 2>/dev/null > exec_sbin_rc
Ma anche con questo miglioramento non ho ottenuto variazioni nel tempo di boot. Quindi sono andato oltre e ho provato a creare la mia lista di file sempre seguendo i consigli postati in quel bug report. Per ottenere la lista dei file ho usato questo e quest’altro script che generano la lista dei file usati dai servizi impostati allinterno dello script. Per impostare i servizi da monitorare basa editare lo script e aggiungere o togliere i servizi desiderati dalla variabile svc. Quindi ne ho creato due copie, uno con i servizi del runlevel boot e uno coi servizi del runlevel default. Lo script genera tanti file di log e li stampa a schermo concatenati, quindi bisogna redirigere l’output dello script su un file oppure concatenare i vari file di log in un unico file. Fare anche attenzione a eventuale output non correlato ai file aperti dai servizi.I file risultanti però son pieni di nomi duplicati e al momento non ho trovato un modo di elimiare i duplicati senza riordinare i nomi dei file. Riordinando i nomi dei file infatti si perdono i benefici del readahead.
Questo è il grafico del boot con i file di configurazione generati via script:
OpenRC parallel boot with readahead-list configured
E anche stavolta non è cambiato nulla…
Analizzando i grafici, i processi che richiedono più I/O sono HAL, X e python (chiamato in causa da wicd), quindi proviamo ad effettuare il readahead dei file che riguardano solo questi tre servizi. Usando gli stessi script generiamo il file di conf.
Ecco il risultato ottenuto:
OpenRC parallel boot with readahead-list configured with just hald, X and wicd
Anche stavolta nessun miglioramento.
Conclusioni:
Nonostante l’idea che sta dietro readahed-list sia molto buona, il mio processore consuma decisamente più dati di quanti ne possa leggere l’hard disk. Quindi il collo di bottiglia è sempre l’hard disk e, come si vede dal grafico, non c’è mai un momento in cui l’utilizzo della CPU superi l’utilizzo del disco. Mancando questo momento non c’è quindi spazio per readahead-list che dovrebbe leggere dal disco nei momenti in cui esso non è utilizzato.
In definitiva readahed-list può risultare un ottimo tool per processori un po datati, o per pc che abbiamo un disco solid state (verificherò anche questo appena posso); mentre si rivela inutile nel caso di processori dual o quad core. Questo si può comunque determinare con più precisione analizzando il grafico generato da bootchart.
FVWM + RoundedCorners
2008-10-31
La config di fvwm che sto usando al momento prevede la patch che arrotonda gli angoli.
Nell’ebuild originale della gentoo la patch non è inclusa, ma sul forum di fvwm si trova.
Il problema è che non patcha più, quindi richiede un po di aggiustamenti… vediamo che riesco a fare…
Anzitutto le patch sono 18 ed è previsto che vengano applicate in cascata, quindi volerne applicare una sola che non sia la prima richiede una conoscenza del codice di fvwm che non ho. Quindi le ho applicate tutte, i cambiamenti necessari riguardavano solo percorsi di file sbagliati e file non più esistenti. Ho anche creato un overlay per ospitare il mio ebuild modificato.
La sintassi del file diff (o patch) è questa; abbastanza semplice.
Istruzioni:
Posizionare la patch in /usr/local/portage/x11-wm/fvwm/files.
Modificare l’ebuild di fvwm aggiungendo le varie patch con epatch “percorso_patch” nella funzione src_unpack, per ogni file di patch (rimuovere anche le patch già previste “ufficialmente” dalla gentoo in quanto già incluse). Ricalcolare il digest dell’ebuild e emergere normalmente fvwm.
ipw3945 vs. iwl3945
2008-10-29
Come al solito non vado d’accordo con le reti…
il passaggio dal vecchio ipw3945 (con relativo demone etc..) al nuovo driver in-kernel iwl3945 è stato un po’ un problema.
La soluzione finale consiste nel seguire questo articolo della gentoo-wiki che si spera risorga in fretta. Per ora ecco il link alla cache di google: iwlwifi
In due parole, abilitare il driver iwl3945 dal kernel più le opzioni di crittografia necessarie; installare il pacchetto net-wireless/iwl3945-ucode.
Installazione e configurazione server
2008-10-26
I server da provare sono: openssh, proftpd, apache, mysql, samba.
L’obbiettivo è averli funzionanti e frugare un po i file di conf.
Installazione:
net-ftp/proftpd (non funziona a causa del bug #221275 la soluzione è indicata, ma devo scoprire come applicare una patch all’ebuild) (ecco come si patcha) (e qui ci sono le patch che vanno applicate al pacchetto tramite l’ebuild) (With the introduction of net-ftp/ftpbase the ftp user is now ftp. Remember to change that in the configuration file.)
virtual/mysql USE=”-berkdb” (deprecated e problematico per amd64)
www-servers/apache
net-fs/samba
Configurazione:
Apache – come al solito è mio amico e non da mai problemi…
Proftpd – il server è facilmente configurabile, gli utenti hanno già accesso con i dati usuali. é necessario configurare gli account anonimi, ma non mi interessano.
Samba – la configurazione è stata fatta senza grossi dubbi o problemi, ma non ho avuto modo di testarla ancora.
Mysql – Ho installato la configurazione con emerge, ma non ho avuto tempo di smanettare.
Programmi "desktop"
2008-10-26
Iniziamo con l’interfaccia grafica.
X era già pronto, mancano solo gli applicativi, ecco quelli che mi interessano:
x11-apps/xdm
net-misc/wicd USE=”-cups” (almeno per il momento)
x11-vm/fvwm USE=”svg tk truetype threads opengl” + USE=”stroke” in package.use
media-video/mplayer USE=”-alsa aac quicktime xvid” + USE=”cdio mmx mmxext sse sse2 ssse3 srt -gtk” in package.use (sono indeciso riguardo a xscreensaver)
media-video/smplayer
rox-base/rox
media-gfx/mirage
x11-terms/mrxvt
app-arch/xarchiver (questo è bruttino, funziona male e ogni tanto crasha… ma sono in ~amd64 quindi ci può stare…)
app-admin/gtkdiskfree
sci-calculators/qalculate-gtk USE=”pdf gd”
app-editors/medit USE=”xml” (mi dispiace lasciare l’onnipotente kate ma ha troppe dipendenze da kde)
questi sono alcuni piccoli tool che uso per abbellire fvwm:
media-gfx/imagemagick
x11-misc/habak
app-admin/conky USE=”hddtemp wifi” + USE=”nvidia” in package.use
x11-misc/transset-df
app-i18n/scim (non ho idea di cosa faccia, controllare)(configura il layout della tastiera, e manco molto bene…)
x11-misc/xcompmgr
x11-misc/trayer
TINT2 (installato a mano, devo creare un ebuild sul mio overlay)
x11-themes/gtk-chtheme
e con i programmi “base” direi che ci siamo; passiamo ai programmi “pesanti”
app-text/epdfview USE=”gtk” (qui sono stato forzato a scegliere tra gtk e qt, per ora gtk, magari qt si aggiunge dopo…)
dev-java/sun-jdk (questo è richiesto da firefox…)
www-client/mozilla-firefox USE=”java xulrunner” (fallito, indagare!!!) (era colpa delle wxwidgets non impostate… risolto!)
net-www/netscape-flash
net-ftp/filezilla
x11-misc/grun
media-gfx/gimp USE=”smp mng”
media-gfx/scrotnet-p2p/qbittorrent (la compilazione fallisce a causa di commoncpp2. Il problema è il bug #236177. é indicata la soluzione.)
app-cdr/graveman USE=”alsa ffmpeg flac ogg dvdr mp3 vorbis” + USE=”amr mmxext ssse3 id3tag” su package.use distribuite tra vari pacchetti.
Da qui in poi sono tutti programmi su cui non ho ancora deciso, perciò passiamo all’installazione e configurazione dei server.
Tool di sistema
2008-10-25
Programmi installati e USE flag che chiamano in causa:
app-admin/system-config-printer (hard masked, “smascherarlo” in seguito)
app-arch/unrar-gpl
app-arch/p7zip
app-arch/unarj
app-arch/arj
app-arch/lha
app-arch/lzop
app-arch/rar
app-arch/unzip
app-arch/zip
app-benchmarks/bootchart (questo servirà solo per riuscire a fare il boot in meno di 30sec)
sys-apps/eject
app-admin/sudo
app-admin/superadduser
www-client/links USE=”fbcon jpeg png tiff svga sdl aalib dga ggi xinerama libcaca imlib”
app-portage/gentoolkit
sys-libs/gpm
sys-apps/gawk
net-analyzer/traceroute
net-analyzer/nmap USE=”-gtk” in package.use (lo uso solo da commandline)
sys-power/cpufrequtils
sys-apps/dbus
app-misc/hal USE=”acpi laptop networkmanager”
sys-power/acpid
app-portage/cfg-update
dev-util/xxdiff (questo ha tirato in ballo le qt3)
net-wireless/ipw3945 (questo è stato problematico)
x11-base/xorg-x11 USE=”hal X xprint”
media-sound/alsa-utils
media-video/linux-uvc
dev-util/strace
sys-process/lsof
Una volta arrivati ad X inizia il grosso del lavoro.
Prima però ci va un emerge -DuN world per uniformare le USE flag fra i programmi installati.
Spazio occupato finora: 3Gb~
Installazione del sistema base
2008-10-25
Partiamo dall’handbook della gentoo; tutto liscio fino al capitolo 5.d.
Qui inizia la personalizzazione.
Ecco il contenuto del file /etc/make.conf
Le cflags che mi interessano sono:
CFLAGS=”-march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -O2 -pipe”
CXXFLAGS=”${CFLAGS}”
MAKEOPTS=”-j3″
CHOST=”x86_64-pc-linux-gnu
ACCEPT_KEYWORDS=”~amd64″
analizzandole:
-march: rappresenta il tipo di processore, il valore core2 corrisponde al mio processore, si può usare solo con gcc >= 4.3.2. Questo implica che per ora userò la keyword ~amd64 per abilitare i pacchetti “instabili”
-mmmx e -m(s)sse*: abilitano le feature mmx e (s)sse del processore.
-O2: ottimizzazione livello 2, buono ma non estremo (instabile)
-pipe: le fasi di compilazione comunicano tramite pipe, incrementa la velocità (generalmente…)
Stessa cosa per le cxx flags.
L’opzione MAKEOPTS è impostata a 3 perchè il core2 ha due cpu, quindi num_cpu+1 = 3
Le altre modifiche fatte al file sono:
USE=”mmx sse sse2″
LINGUAS=”en”
VIDEO_CARDS=”nvidia”
INPUT_DEVICES=”evdev keyboard mouse synaptics”
e si spiegano da sole, a parte la USE che ancora deve essere impostata, ma merita un discorso a parte…
Prima occupiamoci di compilare il kernel, sempre seguendo l’handbook.
Una volta effettuato il chroot cambiamo profilo e mettiamo il no-multilib con
ln -snf /usr/portage/profiles/default/linux/amd64/2008.0/no-multilib /etc/make.profile
vediamo che danni ci porterà un profilo pure 64bit.
Danni ne sono arrivati parecchi… Tra i più gravi: manca una versione funzionante di flash (gnash funziona, ma la CPU schizza alle stelle); wine e skype non possono essere installati. Motivi sufficienti a farmi ritenere che il mondo pure 64 non sia ancora pronto. Cambio profilo in developer. Si fa tramite eselect profile
Vai col kernel e giù fino ai tool di sistema.
Per ora voglio syslog-ng, logrotate, vixie-cron e slocate.
Non ho ancora modificato la USE di default perchè non ce stato bisogno di farlo al momento.
Ricapitolando: ho un sistema base ma ho saltato il passaggio del bootloader e mi manca un client dhcp wire(d|less)
