claudiotomasoni.it

È possibile rendere il caricamento della pagine web in Firefox più veloce attraverso l’utilizzo della tecnica HTTP pipelining.

Normalmente le pagine vengono caricate in maniera sequenziale: viene richiesto il primo oggetto (la pagina) e quando questo è completo viene richiesto il secondo (che può essere un immagine o un filmato flash, ad esempio), quando anche il secondo oggetto è stato ricevuto completamente viene richiesto il terzo, e così via…

L’HTTP pipelining permette di effettuare più richieste in parallelo. Quindi, una volta ricevuta la pagina, è possibile effettuare contemporaneamente le richieste di un certo numero di altri oggetti. Questa tecnica permette anche di includere diverse richieste in un solo pacchetto TCP, riducendo così drasticamente il carico della rete.

Sfortunatamente l’HTTP pipelining è disponibile solo dalla versione HTTP/1.1, perciò i server che ancora utilizzano HTTP/1.0 non sono in grado di soddisfare le richieste pipelined.

Per ragioni cautelative questa funzionalità è disabilitata in Firefox. Abilitarla e osservare il comportamento è il modo più efficace di sapere se può essere sfruttata.

Per abilitare la funzionalità basta digitare “about:config” nella barra degli indirizzi di Firefox e filtrare le voci con l’espressione “pipelining”. Vengono mostrati tre parametri. Per chi utilizza una normale connessione dialup e adsl, generalmente, è sufficiente modificare in “true” il valore relativo a “network.http.pipelining”; mentre per chi è protetto da un server proxy è necessario impostare a “true” il valore relativo a “network.http.proxy.pipelining”.

Nome Parametro                       Stato          Tipo      Valore
network.http.pipelining              personalizzato booleano  True
network.http.pipelining.maxrequest   predefinito    intero    4
network.http.proxy.pipelining        predefinito    booleano  False

Con la voce “network.http.pipelining.maxrequest” c’è la possibilità di indicare quante richieste effettuare in parallelo. Possono essere effettuate contemporaneamente da un minimo di 1 (pipelining disabilitato) ad un massimo di 8 (numeri superiori verranno assunti pari al massimo consentito) richieste. Un numero elevato provoca un ritardo nel completamento della prima richiesta, ma un minor tempo complessivo. Un valore troppo alto potrebbe anche impiegare molto tempo per la formulazione della richiesta, con la conseguente chiusura della connessione e la necessità di dover rieffettuare la richiesta su una nuova connessione. Il valore predefinito, pari a 4 richieste contemporanee, pare essere un buon valore; in alcuni casi potrebbe risultare più efficiente diminuire questo valore a 2 o 3, piuttosto che incrementarlo.

Attenzione: abilitare l’HTTP pipelining non si traduce automaticamente nell’incremento della velocità di caricamento delle pagine web, dal momento che un server che accetta richieste pipelined potrebbe comunque rispondere nella “modalità sequenziale” di HTTP/1.0.

Nota: per saperne di più si può fare riferimento a Wikipedia, alle FAQ sull’HTTP/1.1 pipelining, e per le opzioni di configurazione di Firefox a queste tre pagine.

ClaudioT :: lug.27.2007 :: Fedora, Linux, Tutorial :: No Comments »

Spesso, utilizzando applicazioni come mplayer o tvtime, si osserva che spostando le finestre nell’area di lavoro la riproduzione dei filmati diventa “scattosa”. Un fenomeno analogo si ha quando un servizio è attivo in background (ad esempio il demone di indicizzazione di beagle) e le applicazioni in primo piano diventano meno responsive; o ancora quando si tenta di riprodurre un file musicale in formato midi e il tempo sembra “scivolare” privo della regolarità che ci si aspetterebbe.

Ciò accade perché i programmi lanciati dall’utente si dividono l’utilizzo del processore a intervalli scanditi dal Real Time Clock la cui ampiezza è determinata dalla variabile max-user-freq. Il valore predefinito, che si può leggere con il comando

$ cat /proc/sys/dev/rtc/max-user-freq
64

è spesso troppo basso. Con un valore del genere vengono generati 64 interrupt ogni secondo che le applicazioni utente possono sfruttare per “infilarsi dentro al processore” e fare quel che devono. Di conseguenza quando intervengono applicazioni con priorità più alta (come il window manager di GNOME metacity, quando si spostano le finestre) agli altri processi rimane meno tempo utile per le loro operazioni, e può capitare che non riescano ad eseguire il loro compito nel tempo prestabilito (ad esempio mplayer può saltare la codifica di alcuni fotogrammi, in modo che il tempo trascorso dall’inizio del filmato coincida con il tempo reale).

Il valore così basso è imposto da una politica di tipo conservativo: un valore elevato su vecchi processori può provocare l’accumulo di interrupt con conseguente degrado delle prestazioni. Su una macchina recente tuttavia, il valore predefinito è basso e può provocare i fastidiosi saltellamenti riportati negli esempi.

Ci sono alcuni modi diversi per sistemare la faccenda.

Il primo è temporaneo e la modifica è valida solo fino al successivo riavvio (il comando va dato con i privilegi di amministratore):

# echo 1024 > /proc/sys/dev/rtc/max-user-freq
# cat /proc/sys/dev/rtc/max-user-freq
1024

Anche questo secondo metodo è temporaneo:

# sysctl dev/rtc/max-user-freq=1024

Per rendere permanenti le modifiche si può utilizzare un metodo un po’ meno pulito, consistente nello scrivere nel file /etc/rc.local la riga:

echo 1024 > /proc/sys/dev/rtc/max-user-freq

oppure il metodo del buon amministratore di sistema, che consiste nell’aggiungere al file /etc/sysctl.conf la direttiva:

# Sets the max-user-freq to 1024 to enhance video and games performances
dev.rtc.max-user-freq = 1024

Nota: la spiegazione degli interrupt generati dal Real Time Clock e di come vengono utilizzati è solo spannometrica. Se si desidera saperne di più sull’argomento, si può fare riferimento alla pagina man rtc e alla documentazione del kernel (che nel caso di Fedora si trova in /usr/share/doc/kernel-doc-<versione>/Documentation/rtc.txt).

Aggiornamento!

Nei più recenti kernel il Real Time Clock è stato sostituito dal High Precision Event Timer (HPET), perciò bisogna sostituire hpet ad ogni occorrenza di rtc:

# echo 1024 > /proc/sys/dev/hpet/max-user-freq

# cat /proc/sys/dev/hpet/max-user-freq
1024

In /etc/sysctl.conf va inserita la direttiva:

# Sets the max-user-freq to 1024 to enhance audio/video performances
dev.hpet.max-user-freq = 1024

Alla prossima!

ClaudioT :: lug.26.2007 :: Fedora, Linux, Tutorial :: No Comments »

Fedora è già dotata di una macchina virtuale java: la libreria runtime java per gcc, libgcj.

$ java -version
java version "1.5.0"
gij (GNU libgcj) version 4.1.2 20070502 (Red Hat 4.1.2-12)

Tuttavia si potrebbe volere installare la versione originale di Sun per diversi motivi (per le migliori performance, per evitare crash di qualche programma mal supportato dalla versione di java presente su Fedora, per installare il plugin che permette la visualizzazione delle applet java all’interno del browser).

No, grazie! Va bene così

In questo caso si potrebbe solo voler abilitare il plugin java sperimentale per firefox già presente in Fedora.

Attenzione! Perché

gcjwebplugin is not enabled by default because although the security implementation in GNU Classpath is being actively developed, it is not mature enough to run untrusted applets safely.

Potrebbero essere presenti falle di sicurezza.
Se comunque si desidera abilitare questo plugin sperimentale, è sufficiente un semplice comando:

$ mkdir ~/.mozilla/plugins
$ ln -s /usr/lib/gcj-4.1.2/libgcjwebplugin.so \
        ~/.mozilla/plugins/

È possibile abilitare il plugin system-wide (per tutti gli utenti):

$ sudo ln -s /usr/lib/gcj-4.1.2/libgcjwebplugin.so \
       /usr/lib/mozilla/plugins/

Voglio installare la macchina virtuale java

Se non si ha necessità di installare l’ambiente di sviluppo la cosa si risolve piuttosto semplicemente.
Innanzitutto è necessario visitare il sito java.com e procurarsi l’ultima versione dell’ambiente runtime in formato Linux RPM (file autoestraente). Nel momento in cui scrivo verrà scaricato il file jre-6u2-linux-i586-rpm.bin che contiene il Java Runtime Environment (JRE) 6 Update 2.
È sufficiente eseguire:

$ sudo sh jre-6u2-linux-i586-rpm.bin

Accettata la licenza, il pacchetto RPM verrà installato automaticamente:

$ rpm -q jre
jre-1.6.0_02-fcs

Ora però è necessario dire al sistema di utilizzare la versione di java appena installata. Fedora utilizza il sistema delle alternatives: /usr/bin/java è solo un collegamento simbolico che punta a /etc/alternatives/java, anche questo secondo file è un collegamento che punta al vero binario. Sebbene sia possibile modificare la destinazione del collegamento manualmente, il sistema delle alternatives mette a disposizione dei programmi di utilità più efficienti. Per prima cosa informiamo il sistema che esiste una nuova alternativa:

$ sudo /usr/sbin/alternatives --install \
       /usr/bin/java \
       java \
       /usr/java/jre1.6.0_02/bin/java \
       16002

Successivamente configuriamo l’ambiente perché la utilizzi (in grassetto le righe che richiedono interazione):

$ sudo /usr/sbin/alternatives --config java

Ci sono i programmi 2 che restituiscono 'java'

Selezione      Comando
-----------------------------------------------
 + 1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
*  2           /usr/java/jre1.6.0_02/bin/java

Invio per mantenere l'attuale selezione[+],
o inserire il numero di selezione: 2

Verifichiamo che tutto sia andato per il verso giusto:

$ java -version
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

Ora non rimane che da installare il plugin per firefox:

$ sudo ln -s \
       /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so \
       /usr/lib/mozilla/plugins

Il gioco è fatto.

Voglio l’intero ambiente di sviluppo java

In questo caso la cosa più semplice da fare è Preparare un ambiente per lo sviluppo di pacchetti RPM, scaricare il Java Development Kit dal sito di Sun (al momento in cui scrivo la versione più recente è la 1.6 update 2) in versione auto-estraente (il file si chiamerà jdk-6u2-linux-i586.bin), scaricare da jpackage il sorgente RPM java-1.6.0-sun-1.6.0.2-1jpp.nosrc.rpm (seguire il collegamento java-1.6.0-sun nella sezione non-free).

Il file sorgente RPM andrà installato da utente con:

$ rpm -U java-1.6.0-sun-1.6.0.2-1jpp.nosrc.rpm

Il file jdk-6u2-linux-i586.bin andrà spostato:

$ mv jdk-6u2-linux-i586.bin ~/rpmbuild/SOURCES

Si creano gli RPM che andranno installati:

$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba java-1.6.0-sun.spec

Infine si installano gli RPM prodotti (potrebbe non essere necessario installarli tutti):

$ cd ../RPMS/i586
$ sudo rpm -Uvh java-1.6.0-sun-*

Con questo metodo non c’è bisogno di configurare il sistema delle alternatives, né di installare a mano il plugin per firefox (tutto viene gestito automaticamente dagli RPM).

ClaudioT :: lug.25.2007 :: Fedora, Tutorial :: No Comments »

La versione di me stesso griffata da Matt Groenig è decisamente migliore dell’originale in (molta) carne e (robuste) ossa (grazie a Luca Ferretti).

ClaudioT :: lug.24.2007 :: Facezie :: No Comments »

Oggi (il 24 luglio 2007), su Fedora Daily Package, è apparsa la recensione di un software piuttosto curioso: eSpeak, un sintetizzatore vocale.

Normalmente non uso questi software, ma la recensione mi ha colpito (o dovrei scrivere semplicemente che ero in vena di ca$$eggio?). Di fatto l’ho installato:

$ sudo yum install espeak

Il sito ufficiale riporta che:

eSpeak produces good quality English speech. It uses a different synthesis method from other open source TTS engines, and sounds quite different. It’s perhaps not as natural or “smooth”, but I find the articulation clearer and easier to listen to for long periods.

che per gli italiani monolingua diventa:

eSpeak parla un inglese di buona qualità. Utilizza un metodo di sintesi diverso dagli altri motori di sintesi e suona un po’ differente. Forse non è così naturale o scorrevole, ma il suono è più scandito e più gradevole all’ascolto quando l’utilizzo è prolungato.

Ma la cosa più importante è che:

eSpeak does text to speech synthesis for the following languages, some better than others. Afrikaans, Croatian, Czech, Dutch, English, Esperanto, Finnish, French, German, Greek, Hindi, Hungarian, Icelandic, Italian, Norwegian, Polish, Portuguese, Romanian, Russian, Slovak, Spanish, Swahili, Swedish, Vietnamese, Welsh.

cioè eSpeak legge anche in italiano. Il che significa che non è necessario scrivere cose del tipo:

chow a meecoh, behlla lee, koma tee boot uh?

per fare leggere questo messaggio (non che normalmente io parli così).

eSpeak legge dallo standard input, perciò per leggere un file di testo si può usare la redirezione:

$ espeak < testo.txt

Non sono molte le opzioni di questo programma ed è possibile vederle con --help. Le più interessanti sono: -v che permette di specificare uno dei linguaggi supportati (il comando espeak --voices visualizza la lista completa), -s che permette di regolare la velocità in parole al minuto con un numero tra 80 e 370, -p che permette di cambiare l’intonazione con un numero tra 0 e 99, e -m che ignora tutto ciò che è contenuto tra i segni < e > (utile per leggere pagine html), -w file.wav che permette di riversare la voce su un file audio-wave. Così il comando

$ espeak -v it -f testo-italiano.txt

leggerà il testo in italiano.

Nota: non c’è nessuna pagina man per questo comando, ma la documentazione è installata nella directory /usr/share/doc/espeak-<versione>.

ClaudioT :: lug.24.2007 :: Facezie, Fedora, Linux :: No Comments »

Dopo aver visto come Preparare un ambiente per lo sviluppo di pacchetti RPM, cerchiamo di approfondire un po’ l’argomento analizzando ciò che manca per rendere il pacchetto “distribuibile”.

Attenzione!!! Questo post non spiega come creare pacchetti RPM a partire dai sorgenti, argomento per cui si rimanda all’ottimo Maximum RPM, a questo documento ufficiale, a quest’altra bozza e, in generale, a tutta la restante documentazione presente sul sito ufficiale.

Firmare i pacchetti con un firma gpg

La firma sui pacchetti permette di verificarne l’autenticità. Se si pensa di creare un repository per i pacchetti o anche solo di distribuirli dal proprio sito è opportuno creare una firma digitale attendibile e usarla per gli RPM prodotti.

Per creare una firma digitale attendibile, basta decidere che nome e che indirizzo email utilizzare, e lanciare (le righe in grassetto sono quelle che richiedono interazione):

$ gpg --gen-key
gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Per favore scegli che tipo di chiave vuoi:
   (1) DSA and Elgamal (default)
   (2) DSA (firma solo)
   (5) RSA (firma solo)
Cosa scegli? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
La dimensione richiesta della chiave è 2048 bit
Per favore specifica per quanto tempo la chiave sarà valida.
         0 = la chiave non scadrà
      <n>  = la chiave scadrà dopo n giorni
      <n>w = la chiave scadrà dopo n settimane
      <n>m = la chiave scadrà dopo n mesi
      <n>y = la chiave scadrà dopo n anni
Chiave valida per? (0)
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Nome e Cognome: Nome Cognome
Indirizzo di Email: indirizzo@email.it
Commento: Thats' me!
Hai selezionato questo User Id:
    "Nome Cognome (Thats' me!) <indirizzo@email.it>"

Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit? O
Ti serve una passphrase per proteggere la tua chiave segreta.

Inserisci la passphrase:
Ripeti la passphrase:

L’applicazione provvederà a generare la firma gpg e a salvarne una copia nella directory nascosta .gnupg.

Nota: per esportare la chiave in formato ASCII, utile per la distribuzione, si può usare il comando:

$ gpg --armor --output ChiavePubblica.txt --export indirizzo@email.i

Ora è necessario istruire rpmbuild affinché utilizzi la chiave per firmare i pacchetti prodotti. Si aggiunge in coda al file di configurazione ~/.rpmmacros:

%_signature     gpg
%_gpg_path      /home/%(whoami)/.gnupg
%_gpgbin        /usr/bin/gpg
%_gpg_name      %(gpg --list-keys | sed -n "s/^uid *//p" | head -1)

Nel caso in cui si desideri che l’ultimo campo non sia “calcolato al volo”, si può utilizzare anche la formulazione

[...]
%_gpg_name      Nome Cognome (That's me!) <indirizzo@email.it>

I pacchetti non saranno automaticamente firmati, per includere la firma è necessario accodare l’opzione --sign a rpmbuild:

$ rpmbuild -ba --target=$(uname -m) --sign programma.spec

Verrà chiesta la passphrase con cui si è deciso di proteggere la propria firma.

Controllare la qualità dei pacchetti

Fedora mette a disposizione alcune utilità per verificare la qualità dei pacchetti creati.

L’applicazione rpmlint è in grado di segnalare errori e imprecisioni nel pacchetto. Si installa con

$ sudo yum install rpmlint

È bene controllare ogni RPM prodotto a partire dallo spec file: il file Nome-Versione-Release.src.rpm, i file *.rpm, e anche i file debuginfo. Quando l’output del comando è muto, i file RPM prodotti si possono considerare ragionevolmente privi di errori.

ClaudioT :: lug.17.2007 :: Fedora, Tutorial :: No Comments »

Un ambiente al cui interno poter creare pacchetti RPM può non servire solamente alla produzione di pacchetti nuovi, ma anche al reimpacchettamento di applicazioni già esistenti per le quali si desiderano attivare funzionalità escluse dal pacchetto ufficiale (ad esempio, si potrebbe volere ricompilare qemu per abilitare il supporto adlib).

La procedura per la creazione di uno spazio del genere è piuttosto semplice, constando di due soli semplici passi.

Nel primo passo si costruisce la gerarchia di directory necessaria al processo di creazione dei pacchetti. In Fedora un modello di questa gerarchia esiste già: la directory /usr/src/redhat. Questo spazio è quello in cui l’amministratore di sistema può realizzare pacchetti RPM; poiché non è mai una buona idea creare RPM da amministratore (operazioni maldestre potrebbero compromettere l’intero sistema) copiamo questa gerarchia in uno spazio a noi accessibile, ad esempio la nostra home directory:

$ cp -R /usr/src/redhat ~/rpmbuild

Osserviamo cosa è contenuto nella nuova directory rpmbuild:

BUILD	-> La directory in cui i sorgenti vengono spacchettati
RPMS	-> La directory che conterrà gli RPM creati, divisi per architettura
SORCES	-> La directory che contiene i sorgenti compressi e le patch
SPECS	-> La directory che contiene le istruzioni per creare gli RPM
SRPMS	-> La directory che conterrà gli RPM sorgenti

Il secondo passo prevede la preparazione del file di configurazione .rpmmacros all’interno della propria home directory. Ecco un set di direttive fondamentali per questo file:

%packager       Nome Cognome <indirizzo@email.it>
%dist           .f%(tr -cd [0-9] < /etc/fedora-release)
%vendor         BSI%_topdir        /home/%(whoami)/rpmbuild

%_smp_mflags    -j3

%__arch_install_post /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

La direttiva %packager serve a definire il nome del creatore del pacchetto (e il suo indirizzo email).
La direttiva %dist permette di inserire un tag rappresentativo della versione della distribuzione nel nome del file RPM (così un pacchetto per Fedora 7 si chiamerà nome-versione-release.f7.architettura.rpm).
La direttiva %vendor definisce una Breve Sigla Identificativa con cui segnalare la provenienza del pacchetto.
La direttiva %_topdir è la più importante e definisce la directory al cui interno si trova la struttura gerarchica necessaria al processo di costruzione di pacchetti RPM (nel nostro caso la directory che abbiamo copiato con il primo comando cp). All’interno del percorso è stato usato %(whoami) che viene espanso automaticamente al nome dell’utente che lancia il comando per creare il pacchetto (ma si può anche scrivere il nome della directory per esteso).
La ultime due direttive non sono fondamentali; la prima serve per indicare quanti processi di compilazione possono essere condotti parallelamente, la seconda per controllare che i percorsi di binari e librerie siano corretti (in realtà è una cosa più complessa, ma quest’accenno è sufficiente).

A questo punto l’ambiente è pronto.

Ricompilare pacchetti

Per ricompilare un pacchetto localmente si deve disporre del comando rpmbuild che può essere installato con:

$ sudo yum install rpm-build

Vediamo il caso pratico della ricompilazione di qemu con l’abilitazione del supporto adlib.
Innanzitutto è necessario scaricare il pacchetto sorgente. Ci sono molti modi: uno è scaricarlo direttamente dal sito ftp di fedora, oppure è possibile servirsi di http://rpm.pbone.net, o ancora si può utilizzare l’utilità yumdownloader. Vediamo quest’ultimo caso: installiamo innanzitutto l’applicazione con

$ sudo yum install yum-utils

e poi utilizziamola per procurarci il pacchetto sorgente di qemu con

$ sudo yumdownloader --source qemu

Il file qemu-<versione>-<release>.src.rpm verrà scaricato nella directory di lavoro corrente. Possiamo installarlo con il comando

$ rpm -U qemu <versione>-<release>.src.rpm

Attenzione!!! Il pacchetto sorgente deve essere installato senza i privilegi di amministratore. Una volta installato è possibile cancellarlo.

A questo punto ci spostiamo nella directory ~/rpmbuild/SPECS che contiene le istruzioni per creare i pacchetti (sotto forma di un file con estensione .spec) ed editiamo il file che troviamo all’interno con l’editor preferito:

$ cd ~/rpmbuild/SPECS
$ gedit qemu.spec

Cerchiamo la riga che contiene la direttiva ./configure (potremmo trovare al suo posto la macro %configure) e modifichiamo le opzioni di configurazione secondo le esigenze, ad esempio

[...]
./configure
    --prefix=%{_prefix}
    --interp-prefix=%{_prefix}/qemu-%%M
    --cc=gcc%{gccver}
    --enable-alsa
[...]

diventa

[...]
./configure
    --prefix=%{_prefix}
    --interp-prefix=%{_prefix}/qemu-%%M
    --cc=gcc%{gccver}
    --enable-alsa
    --enable-adlib
[...]

Salviamo e ricompiliamo il pacchetto con il comando:

rpmbuild -ba --target=$(uname -m) qemu.spec

Se compare l’avvertimento che mancano pacchetti necessari alla compilazione, questi vanno installati con yum. Alla fine del processo troveremo il pacchetto RPM in una sottodirectory di ~/rpmbuild/RPMS, secondo l’architettura del nostro computer.

Attenzione!!! Questa non è una guida su come creare pacchetti RPM, ma su come preparare un ambiente per la creazione di pacchetti in Fedora (ed un esempio del perchè potrebbe servire). Per la creazione di pacchetti RPM si può fare riferimento all’ottimo Maximum RPM, a questo documento ufficiale e a quest’altra bozza.

ClaudioT :: lug.17.2007 :: Fedora, Tutorial :: 2 Comments »

Sebbene non sia sbagliato inserire un comando all’interno del file /etc/rc.local, non è il metodo più pulito per caricare un modulo all’avvio di Fedora. Il comportamento più corretto è di creare un file eseguibile all’interno della directory di configurazione di sistema /etc/sysconfig/modules/. Supponendo di voler caricare il modulo kqemu per incrementare le prestazione del virtualizzatore qemu, dovremo creare un file dal nome kqemu.modules (questo nome deve essere indicativo per noi, per il sistema è indifferente) che contiene:

#!/bin/sh
modprobe kqemu >/dev/null 2>&1

Il file deve essere reso eseguibile, perciò sarà necessario dare

$ sudo chmod a+x /etc/sysconfig/modules/kqemu.modules

Il comando funziona se avete configurato sudo, altrimenti bisogna effettuare l’autenticazione con su.

Specificare opzioni

Alcuni moduli accettano opzioni aggiuntive che permettono di controllare meglio l’hardware. È possibile conoscere queste opzioni con una riga del tipo (supponendo di volere vedere quelle del modulo snd-emu10k1):

$ sudo /sbin/modinfo snd-emu10k1 | grep -e parm:
parm:           index:Index value for the EMU10K1 soundcard. (array of int)
[...]
parm:           enable_ir:Enable IR. (array of bool)

Opzioni e alias per i dispositivi possono essere inseriti all’interno di /etc/modprobe.conf o in un file contenuto nella directory /etc/modprobe.d. Ecco ad esempio quale potrebbe essere il contenuto di modprobe.conf:

alias snd-card-0 snd-emu10k1
options snd-card-0 index=0 enable_ir=1

La prima riga dice che ci si può riferire al driver per le schede Audigy con il nome di snd-card-0, così da potersi dimenticare quale driver specifico controlla la periferica (basta ricordarsi che è la scheda audio numerata con 0). Le due successive specificano opzioni per il dispositivo hardware; la seconda, ad esempio, ordina al driver di abilitare il ricevitore a raggi infrarossi presente sul pannello frontale della scheda.

ClaudioT :: lug.15.2007 :: Fedora, Tutorial :: No Comments »

Il menu delle applicazioni contiene le voci che permettono di avviare programmi provenienti dai diversi pacchetti installati.

Ormai è piuttosto noto che per modificare una voce di menu è necessario modificare il file con estensione .desktop da cui questa legge i dati. Secondo gli standard dettati da freedesktop.org questi file si trovano all’interno della directory /usr/share/applications.

Per conoscere le voci di menu installate insieme ad un pacchetto, ad esempio GIMP, in un sistema rpm-based si può digitare all’interno di un terminale:

rpm -ql gimp | grep desktop
/usr/share/applications/gimp-2.2.desktop
/usr/share/gimp/2.0/misc/gimp.desktop

Creare una nuova voce in un sotto-menu esistente

Per aggiungere all’interno di un sotto-menu esistente, ad esempio Grafica, una nuova voce di avvio, ad esempio uno shortcut che apra la documentazione di GIMP, è necessario creare ed editare un file con estensione .desktop. Poiché non abbiamo la minima voglia di crearne uno dal nulla, ne useremo uno esistente come base. Il file /usr/share/applications/gimp-2.2.desktop crea lo starter di GIMP proprio nel sotto-menu Grafica che ci interessa, perciò usiamo questo (prima è utile avere configurato sudo):

$ cd /usr/share/applications
$ sudo cp gimp-2.2.desktop gimp-doc.desktop

A questo punto possiamo modificare gimp-doc.desktop con un editor:

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=Documentation for the GIMP
Name[it]=Documentazione per GIMP
Comment=Read the online documentation for the GIMP
Comment[it]=Accede alla documentazione in linea di GIMP
Exec=htmlview /usr/share/gimp/2.0/help/it/index.html
Icon=gimp.png
Terminal=false
Categories=Graphics;2DGraphics;RasterGraphics;GTK;
StartupNotify=false

Osserviamo che un file desktop è un elenco di direttive:

• Name definisce il nome del collegamento; Name[it] permette di localizzare il nome nelle diverse lingue.
• Comment definisce il testo del suggerimento che appare quando il puntatore è fermo sul collegamento; Comment[it] è la localizzazione nella lingua indicata tra parentesi quadre.
• Exec indica il comando che deve essere eseguito (/usr/share/gimp/2.0/help/it/index.html è il file di partenza della guida di GIMP, mentre htmlview è un helper che lancia il browser predefinito del desktop environment in uso con l’argomento che lo accompagna).
• Icon specifica un’icona per la voce di menu; può essere indicato il percorso assoluto, oppure il solo nome dell’icona (che verrà cercata nelle directory che contengono le icone del tema corrente).
• Terminal indica se il programma deve essere aperto in un terminale (utile ad esempio per creare uno starter per l’interprete python o per programmi come octave).
• StartupNotify specifica se segnalare nell’Elenco finestre che è stato eseguito il comando indicato (è utile mettere questa voce a false per helper come htmlview o per programmi che vengono lanciati in modalità demone).
• Categories specifica le categorie cui è inerente la voce di menu; in base a queste verrà deciso il posizionamento all’interno dell’albero dei menu.

Nel nostro esempio, rispetto al modello originale, sono state cambiate le direttive Name, Name[it], Comment, Comment[it], Exec, StartupNotify e Categories.

Ecco il risultato ottenuto:

Con la stessa icona di GIMP è presente la nuova voce che permette di accedere alla documentazione in italiano.

Creare una nuova gerarchia di sotto-menu

Potremmo volere che le nostre nuove voci di menu non appartengano a nessuno dei sotto-menu esistenti, ma che siano all’interno di un nuovo sotto-menu. Ad esempio potremmo desiderare di avere un sotto-menu Applicazioni Google al cui interno far apparire le voci Google Docs, Google Earth, Picasa, Gmail, e via seguendo…

La struttura dei sotto-menu è controllata da file xml con estensione .menu contenuti nella directory /etc/xdg/menus. Non è consigliabile modificare i file di configurazione qui contenuti; per aggiungere il nostro nuovo menu creeremo un file chiamato google.menu all’interno della directory /etc/xdg/menus/applications-merged, locazione apposita per permettere le modifiche al menu senza intaccare la struttura originale predefinta (e quindi evitando di non avere più a disposizione nessun menu a causa di eventuali errori di sintassi). È facile capire la struttura del nuovo file xml:

<!DOCTYPE Menu
    PUBLIC '-//freedesktop//DTD Menu 1.0//EN'
    'http://standards.freedesktop.org/menu-spec/menu-1.0.dtd'>
<Menu>
    <Name>Applications</Name>
    <Menu>
        <Name>Google Applications</Name>
        <Directory>Google.directory</Directory>
        <Include>
            <Category>Google</Category>
        </Include>
    </Menu>
</Menu>

A questo punto il nuovo sotto-menu esiste, ma non è visibile perché non contiene nessuna voce.
Creiamo uno shortcut per Google Docs: per farlo basta creare con i privilegi di amministratore il file /usr/share/applications/google-docs.desktop. Eccone il possibile contenuto:

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=Google Docs
Comment=Google Documenti e Fogli di Lavoro
Exec=htmlview http://docs.google.com/?hl=it
Icon=googledocs.png
Terminal=false
Categories=Google;
StartupNotify=false

L’icona googledocs.png, è un’immagine scelta a piacere e copiata in /usr/share/pixmaps.

Se cercassimo ora nel menu Applicazioni vedremmo il nuovo contenitore Google Applications al cui interno si trova lo starter per Google Docs. Osserveremmo però che il sotto-menu non ha un’icona personalizzata e il suo nome non è localizzato; per risolvere questo ultimo problema è necessario creare il file Google.directory (il nome deve essere quello indicato nel file /etc/xdg/menus/applications-merged/google.menu da noi creato) all’interno della directory /usr/share/desktop-directories:

[Desktop Entry]
Name=Google Apps
Name[it]=Applicazioni Google
Icon=google.png
Type=Directory
Encoding=UTF-8

Anche qui l’immagine google.png è stata scelta a piacere e posta in /usr/share/pixmaps.

Il risultato lo si può vedere nell’immagine che segue:

NOTA: questa procedura è stata testata in GNOME, nessuna idea se funzioni anche per KDE.

ClaudioT :: lug.13.2007 :: Fedora, Linux, Tutorial :: No Comments »

L’utilità di sistema sudo fornisce un’alternativa efficiente a su. Una volta provato a mantenere un sistema a colpi di questa piccola applicazione (come accade con Ubuntu) non se ne può più fare a meno (almeno questo è il mio caso). Purtroppo “ubuntizzare” l’intero sistema, compresi i programmi di utilità con interfaccia grafica, è un’operazione molto complessa e onerosa. Tuttavia, configurare sudo per l’utilizzo all’interno del terminale è una sciocchezza.

Bisogna acquisire i diritti di amministratore di sistema e lanciare il comando visudo:

$ su -
Parola d'ordine:
# visudo

Il trattino è importante perché rende la shell una shell di login, il che impone la lettura del profilo di root e quindi la modifica della variabile PATH che in questo modo include anche le directory /sbin e /usr/sbin. Senza trattino non avremmo potuto lanciare semplicemente il comando visudo, ma avremmo dovuto riferirci ad esso attraverso il suo percorso completo /usr/sbin/visudo. Il comando visudo permette di modificare senza errori il file di configurazione /etc/sudoers (questo speciale editor rifiuta di salvare il file se vi abbiamo scritto sciocchezze).

Per effettuare la modifica che ci interessa cerchiamo la riga

## Allows people in group wheel to run all commands
#%wheel  ALL=(ALL)       ALL

e modifichiamola in

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

togliendo il simbolo di commento #.

In questo modo è permesso a ogni utente appartenente al gruppo wheel di utilizzare il comando sudo. Se l’utente pincopallo non appartiene al gruppo si otterrà un messaggio di errore:

$ sudo ls /root/
Password:
pincopallo is not in the sudoers file.  This incident will be reported.

Per aggiungere l’utente pincopallo al gruppo wheel si può usare il comando usermod con i privilegi di amministratore:

# usermod -aG wheel pincopallo

Non dimenticate la lettera a tra le opzioni o pincopallo perderà l’appartenenza a tutti gli altri gruppi in cui si trovava precedentemente al comando.

ClaudioT :: lug.13.2007 :: Fedora, Tutorial :: 2 Comments »