Posts RSS Comments RSS 28 Articoli e 6 Commenti fino ad ora

Post nella categoria 'Linux'

WINE e Fedora 13

Ma guarda un po’, dopo l’aggiornamento a Fedora 13:

$ winecfg
wine: could not exec wineserver

Allora:

$ sudo yum search wineserver
[...]
Nessuna corrispondenza trovata

gughela, gughela, gughela…

$ sudo yum info wine-wow
Name        : wine-wow
Arch        : i686
Version     : 1.3.1
Release     : 1.fc13
Size        : 540 k
Repo        : updates-testing
Summary     : Files for wine wow seperation
URL         : http://www.winehq.org/
License     : LGPLv2+
Descrizione : Files for wine wow seperation

Ma che diavolo vuol dire wine wow separation?
Non si poteva proprio usare una descrizione diversa, tipo bunch of files that wine needs to run properly oppure The wine-wow package provides the wineserver service?
E magari aggiungere una dipendenza? (la dipendenza non c’è né in updates, né in updates-testing)

Comunque:

$ sudo yum install wine-wow

oppure su sistemi x86_64*

$ sudo yum install wine-wow.i686

risolve il problema.

* Sui sistemi x86_64 non devono essere installati pacchetti di wine per processori a 64 bit, ma solo pacchetti per i686 (a meno che non dobbiate fare girare programmi compilati a 64 bit per Windows a 64 bit).

mod + x86_64 = crash

Questo titolo può apparire strano ai più, ma chi usa la libreria libmodplug (ad esempio chi usa un player basato su gstreamer, come totem o rhythmbox, oppure xmms, o ancora audacious) oltre a non sentire niente e a incappare in un colossale crash del player preferito, sa di cosa scrivo.

Perché ho l’impressione che qualcuno guarda con occhi bovini il nero testo, chiedendosi cosa è la musica in formato mod?
Ahimé, nato in un altro secolo, in un altro millennio… quando c’erano gli Amiga e i floppy da 5″ e un quarto (ci stavano ben 160 kB!) e i PC erano scaldabagni a 12 MHz (sì, ma 33 col turbo!) con 640 kB di RAM e dischi da 16 MB.
Caprettech che non siete altro! Fatevi un idea su The Mod Archive.

Dicevamo: il player va in crash a causa di un problema nella libreria libmodplug versione 0.8.7, solo sui sistemi a 64 bit.

Mentre Ubuntu pare avere aggiornato la libreria alla versione 0.8.8.1, che risolve il problema, per Fedora l’aggiornamento non è nemmeno in updates-testing (al momento in cui scrivo).
Poiché i tentativi di installare il pacchetto ricompilato dall’rpm sorgente preso da Rawhide falliscono miseramente (non ci ho nemmeno provato tanto, in realtà, a modificare il file spec), ecco un trucco per tornare a godere della meravigliosamente vintage collezione di musica.

Prima di tutto, serve scaricare la libreria da qui. Si può scaricare il sorgente, oppure il pacchetto precompilato che non si installerà a causa di problemi di dipendenze.
Partendo dal sorgente, sarà necessario installare tutte le sacrosante dipendenze e dare la solita sequenza magica ./configure --prefix=/usr --libdir=/usr/lib64 && make.
Preso il pacchetto, invece, si dovranno vedere i file contenuti (ad esempio con file-roller), oppure estrarli con rpm2cpio <nome_del_file.rpm> | cpio -idmv.

Quel che conta è arrivare ad avere il file libmodplug.so.1.0.0.
Bellamente disinteressati all’incoerentissimo numero di versione, copiamo la nuova libreria al posto della vecchia:

$ sudo cp libmodplug.so.1.0.0 /usr/lib64/libmodplug.so.0.0.0

oppure, per chi non ha configurato sudo, con un altrettanto efficace:

$ su
Password:
# cp libmodplug.so.1.0.0 /usr/lib64/libmodplug.so.0.0.0

Per vedere se la cosa è andata a buon fine, si può provare a lanciare:

$ cd
$ wget http://www.claudiotomasoni.it/files/audio/TheGunDance.xm
$ gst-launch-0.10 -v playbin uri=file:///home/<vostra home>/TheGunDance.xm

Il rimedio è un po’ brutale, però da me ha funzionato.
Alla prossima…

deskbar-applet

Ma perché la finestra delle preferenze della deskbar-applet continua ad andare in crash? Cosa ci vuole nel duemilaecento a correggere un bug del bradvice?

Basta cambiare una cifra in prefs-dialog.ui!

In una distribuzione rpm-based, per trovare il file è sufficiente:

$ rpm -ql deskbar-applet | grep prefs-dialog.ui

Bisogna trovare la linea che contiene l’etichetta “label1315″:

[...]
 <object class="GtkLabel" id="label1315">
[...]

e cambiarla in “label1314″:

[...]
 <object class="GtkLabel" id="label1314">
[...]

Flash e CPU al 100%

Ammetto che il computer di casa non è proprio un giovane marinaio (Athlon XP 2000+ sì, ma con 2 Giga di RAM – mica poca!), però che non riesca a vedere i video di youtube (e mica solo quelli) perché continuano a saltellare-scricchiolare-perderefreims, quello no! Sono filmati flash, diavolo!

È piuttosto schifoso che Adobe rilasci un plugin con queste richieste hardware (prese da qui):

per windows, un processore ad almeno 450 MHz e 128 MB di memoria
per linux, un processore ad almeno 800 MHz e 512 MB di memoria

Il doppio del processore e il quadruplo della RAM! Un plugin ottimizzato come me quando mi alzo alle 5 di mattina.

Comunque, il peggio lo scopro quando vado a vedere chi è il succhiatore di linfa (un bel top in un terminale): npviewer.bin sta andando a braccetto con il plugin flash. Che ragioni ci sono per un pezzo di software che non è nemmeno chiamato in causa? (npviewer non serve a flash).

Disinstallo il pacchetto nspluginwrapper e i maledetti saltellamenti-schricchiolii-perditedifreims si dimezzano. Ma non spariscono. Maledetta Adobe! Se solo gnash funzionasse…

PS: no! non azzardatevi a scrivere che funziona. L’ho già provato e sul mio computer non funziona.
PPS: uno dei video che vorrei vedere è questo…

Decisamente vale la pena di vederlo senza scatti. Alla prossima.

Acer ASPIRE 2920 e Fedora (10 Cambridge)

(Non troppo) recentemente ho acquistato un nuovo portatile: un Acer ASPIRE 2920, dotato di

  • processore Intel Core 2 Duo T7500
  • 2 GB di RAM DDR2
  • disco da 250 GB
  • masterizzatore DVD Dual Layer
  • WiFi Intel PRO/Wireless e scheda ethernet Broadcom Gigabit
  • bluetooth (non meglio identificato)
  • chip grafico Intel X3100
  • monitor WXGA da 12″ con risoluzione massima pari a 1280×800 (rapporto 16:10)
  • webcam Crystal Eye integrata

Acer ASPIRE 2920

Il nuovo portatilino, leggero e contenuto nelle dimensioni, pagherà le marchette per il vecchio Compaq (giunto prematuramente alla fine dei suoi giorni, dopo il sovrautilizzo per la tesi – requiescat in pacem).

Nessun problema di installazione con Fedora. L’hardware è ampiamente riconosciuto e correttamente configurato, ad eccezione di due minuscoli particolari.

Chip audio
L’audio c’è, ma a basso volume, e inserire il cavo delle cuffie non mette a tacere gli altoparlanti esterni (in queste condizioni, guardare un filmato pornografico è estremamente complicato, se si cerca di farlo di nascosto). La soluzione c’è ed è piuttosto banale: basta creare un file /etc/modprobe.d/alsa-base ed inserirvi all’interno

options snd-hda-intel model=acer

Risoluzione del frame buffer
La risoluzione 1280×800 non è contemplata dallo standard VGA. Però c’è un trucco.
E’ necessario installare l’utility vbetest (con yum o il frontend grafico) e impartire l’omonimo comando da terminale come amministratore:

$ sudo vbetest
VBE Version 3.0
Intel(r)GM965/PM965/GL960 Graphics Chip Accelerated VGA BIOS
[352] 1280x800 (256 color palette)
[353] 1280x800 (5:6:5)
[354] 1280x800 (8:8:8)
[261] 1024x768 (256 color palette)
[279] 1024x768 (5:6:5)
[280] 1024x768 (8:8:8)
[274] 640x480 (8:8:8)
[276] 800x600 (5:6:5)
[277] 800x600 (8:8:8)
[257] 640x480 (256 color palette)
[259] 800x600 (256 color palette)
[273] 640x480 (5:6:5)
Type a mode number, or 'q' to quit - q

Al numero riportato tra parentesi quadre va aggiunto il valore 512, per ottenere il testo da inserire dopo vga= in grub.conf. Perciò, se vogliamo la risoluzione massima consentita dal pannello LCD (cioè 1280×800) al numero massimo di colori possibile (5:6:5 darà una profondità di colore di 16bit, mentre 8:8:8 una profondità di 24 bit), dovremo calcolare 354+512=866 e inserirlo in coda alla riga corretta in grub.conf:

[...]
kernel /vmlinuz ro root=UUID=omissis rhgb quiet vga=866

E questo è tutto.
Bye bye.

Octave 3.0.0

Dopo molto tempo di assenza, che ha fatto sembrare questo spazio più abbandonato di una città fantasma nel deserto (almeno quella ha le folate di vento e i cespugli secchi che rotolano), l’uscita (non recentissima) di Octave mi dà lo spunto per scribacchiare qualcosa e resuscitare dal torpore in cui i nuovi impegni lavorativi mi avevano fatto sprofondare.

Cosa è Octave?

Octave è:

a high-level language, primarily intended for numerical computations. It provides a convenient command line interface for solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with Matlab.

cioé:

un linguaggio ad alto livello, pensato innanzitutto per i calcolo numerico. Dispone di una comoda interfaccia a linea di comando per la soluzione di problemi numerici lineari e non-lineari e per effettuare altri esperimenti numerici, con un linguaggio che è per lo più compatibile con Matlab.

Cosa ha di speciale?

Per quanto mi riguarda, innanzitutto, il fatto di essere compatibile con Matlab e di essere rilasciato sotto licenza GPL. In seconda battuta, ha una serie di toolboxes, molte delle quali (“toolboxes” è femminile, o no?) simili (talvolta compatibili) a quelle a disposizione per Matlab; infine possiede delle sufficienti (ed espandibili) capacità grafiche.

C’è anche, fatto non trascurabile, una vasta ed esauriente documentazione, mantenuta da una comunità di utenti molto attenta e attiva.

Personalmente, l’ho usato da studente per sostenere l’esame di Calcolo Numerico durante i passati anni universitari, poi utilizzato qua e là in qualche altro corso.

Dove sta la magagna?

Già! Octave non è tutto rose-e-fiori!
L’aspetto che trovo più fastidioso è quello di non avere un front-end ben curato e confortevole (come appunto Matlab). Ultimamente persino Scilab sembra stia migrando verso un aspetto più moderno e integrato (si può già avere un assaggio provando scilab-gtk). Octave gira all’interno di una sessione di terminale, usa gnuplot (che è straordinario, anche senza caratteri con l’anti-alias) per generare grafici, e emacs (io lo odio!) oppure vim come editor per gli m-files.

Alcune proposte interessanti per Octave

Dal momento che non tutti, me per primo, appartengono alla chiesa dei duri-e-puri (quelli da sessione di X con 50 terminali aperi da cui controllano anche la politica americana), eccomi a proporre alcuni suggerimenti per migliorare “l’usabilità” (concetto davvero relativo) di Octave.

Proposta 1: creare una cartella all’interno della propria home-directory per contenere gli m-files creati con Octave. Il percorso della directory è obbligato: ho provato a dire al programma di salvare i files in posizioni diverse e di mio gradimento, ma lui sembra costantemente infischiarsene. Perciò:

$ mkdir ~/octave

Proposta 2: creare un file .octaverc all’interno della propria home per fare sapere a Octave di cercare i propri m-files in quella directory. All’interno di questo file si possono inserire tutti gli “octave-comandi” che si vogliono fare mangiare al programma prima dell’avvio della sessione di lavoro. In particolare nel nostro ci sarà:

addpath ('~/octave');

In questo modo si possono richiamare i propri m-files senza dovere essere nella directory ~/octave. Tipicamente il comando edit mfile.m salva un nuovo file nella directory citata, ma la directory di lavoro è quella da cui viene avviata l’applicazione (normalmente la propria home se Octave è avviato facendo click su un icona di menu), perciò suggerisco di aggiungere la nostra bella directory al path.
Proposta 3: emacs mi fa schifo, l’ho già scritto! e vim non è abbastanza molle-e-impuro. Perciò, per chi come me, vuole editare i propri m-files con gedit, lo stratosferico editor di testo predefinito di GNOME, può ricorrere ad un trucchetto. Prima di tutto bisogna creare un file eseguibile in una posizione accessibile, che nel mio caso era /usr/local/bin, ma che può essere qualunque:

$ cd /usr/local/bin
$ sudo touch medit
Parola d'ordine:
$ sudo chmod a+x medit

All’interno del file creato bisogna inserire:

#!/bin/bash

OPTS=$@

/usr/bin/gedit $OPTS &> /dev/null &

exit 0

Ed infine, per istruire Octave ad utilizzare il nostro “nuovo” editor, serve inserire nel file ~/.octaverc la linea:

EDITOR ('/usr/local/bin/medit');

D’ora in poi, il comando edit pippo.m permetterà di editare l’m-file con il miglior editor del mondo.

Oltre le proposte

Per espandere le funzionalità offerte da Octave si può ricorrere a due strumenti esterni: QtOctave, un front-end scritto in QT che sembra avere molte qualità, ma che non ho ancora avuto modo di provare; Octaviz, un’estensione per Octave che permette di usare le librerie VTK per disegni e grafici (trovo Octaviz eccezionale).

Per finire…

vi lascio con un’immagine del mio “desktop running Octave”

Octave 3.0.0

Alla prossima!

Creative Zen Nano Plus

Il Creative Zen Nano Plus è un piccolo lettore mp3-wma capace di registrare dal microfono incorporato o da un ingresso line-in e dotato di radio FM e euqlizzatore a 5 bande. Ha molti pregi, in primis quello di essere davvero leggero e poco ingombrante, e poi quello di avere una qualità musicale davvero molto buona (risposta da 20 Hz a 20 KHz con una distorsione armonica inferiore a 0,1% e rapporto segnale rumore pari a 90 dB).

Il piccolo lettore multimediale Zen Nano Plus prodotto da Creative

Sotto Linux viene normalmente montato come un dispositivo di memorizzazione di massa usb (cioè come una comune chiavetta), perciò è possibile utilizzare un file-manager per organizzare la collezione di brani sul lettore.

Questo lettorino utilizza il protocollo mtp (media transfer protocolo), quindi è possibile utilizzare anche applicazioni più sofisticate come rhythmbox (la mia preferita), gnomad2 o amarok per gestirne il contenuto.

Purtroppo spesso è necessario compiere alcune operazioni di configurazione, la prima delle quali è installare (se non ancora installate) le librerie libmtp con

$ sudo yum install libmtp

Assicuriamoci ora di far partire l’applicazione desiderata (rhythmbox nel mio caso) quando viene connesso un riproduttore portatile. In GNOME si può controllare questa funzionalità dall’utilità Unità e supporti rimovibili presente nel menu delle Preferenze:

Quando viene inserito un riproduttore portatile viene lanciato rhythmbox

Leggiamo, dopo avere connesso il dispositivo, l’identificativo del produttore e dell’apparecchio con il comando

$ /sbin/lsusb
Bus 004 Device 006: ID 041e:4139 Creative Technology, Ltd Zen Nano Plus

L’identificativo del produttore è 041e, mentre quello del prodotto è 4139.

All’interno della directory /etc/udev/rules.d cerchiamo se esistono regole per lo Zen Nano Plus: se l’esito del comando grep 4139 è vuoto significa che non ci sono istruzioni per udev su come gestire il dispositivo. Possiamo aggiungerle manualmente creando il file ZenNanoPlus.rules (o anche un nome più esplicito, come 60-ZenNanoPlus-libmtp.rules, che indica che il dispositivo deve essere gestito dalle librerie mtp) contenente:

# UDEV-style hotplug map for Creative Zen Nano Plus
# Put this file in /etc/udev/rules.d

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="libmtp_rules_end"

# Creative Zen Nano Plus
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4139", SYMLINK+="libmtp-%k", MODE="666"

LABEL="libmtp_rules_end"

Se dopo avere aggiunto queste regole il riproduttore musicale scelto non viene lanciato automaticamente quando lo Zen Nano Plus viene connesso, significa che il demone hal non lo identifica come riproduttore audio portatile, ma come dispositivo di memorizzazione di massa. Per ovviare al problema spostiamoci nella directory /usr/share/hal/fdi/information/10freedesktop e osserviamo se esistono regole per il nostro lettorino:

$ cd /usr/share/hal/fdi/information/10freedesktop
$ grep 4139 *

Se il comando grep non restituisce nulla, allora è necessario creare una regola. All’interno di questa directory, con i privilegi di amministratore, creiamo il file 10-usb-music-players-libmtp-ZenNanoPlus.fdi contenente:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
  <device>
    <match key="info.category" string="storage">
      <!-- USB Mass Storage devices that are music players -->
      <match key="@storage.originating_device:info.subsystem" string="usb">
        <!-- Creative -->
        <match key="@storage.originating_device:usb.vendor_id" int="0x41e">
          <!-- Zen Nano Plus -->
          <match key="@storage.physical_device:usb.product_id" int="0x4139">
            <append key="info.capabilities" type="strlist">portable_audio_player</append>
            <merge key="info.category" type="string">portable_audio_player</merge>
            <merge key="portable_audio_player.type" type="string">generic</merge>
            <merge key="portable_audio_player.access_method" type="string">storage</merge>
            <append key="portable_audio_player.output_formats" type="strlist">audio/mpeg</append>
            <append key="portable_audio_player.output_formats" type="strlist">audio/x-ms-wma</append>
            <append key="portable_audio_player.output_formats" type="strlist">audio/x-wav</append>
          </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

A questo punto, dopo avere riavviato il demone hal con sudo /etc/init.d/haldaemon restart, quando lo Zen Nano Plus viene inserito, dovrebbe essere avviato automaticamente il riproduttore multimediale scelto e sul Desktop dovrebbe essere mostrata il dispositivo con l’icona di un lettore portatile associata.

Pagine man colorate

Le pagine man colorate aiutano a trovare, a colpo d’occhio, le informazioni più utili all’interno della pagine di aiuto visualizzata e migliorano la comprensione.

I terminali Linux sono capaci di cose come colorare il testo o aumentarne il peso (grassetto), così da rendere più gradevole e produttiva la sessione di lavoro, attraverso le terminal capabilities. Tra le applicazioni che supportano le termcap c’è anche il pager delle pagine man: less.

Alcune variabili speciali permettono di stabilire i colori da utilizzare; se queste vengono inserite nel file speciale .bashrc, saranno disponibili come variabili di ambiente e le pagine man saranno sempre colorate.

Ecco cosa si potrebbe inserire in .bashrc:

export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'

In questo modo il comando man man mostrerà:

Pagine man colorate

Questo metodo produce però alcuni effetti collaterali sgradevoli. Ecco cosa accade digitando env:

Effetto collaterale non gradito

Questo accade, probabilmente, perché env ricorre ad un pager sensibile alle termcap. Se si pensa di non poter sopravvivere un giorno in più, in questo mondo troppo colorato che elenca in modo così squinternato le variabili di sistema, si possono comunque avere le pagine man colorate senza questo effetto collaterale semplicemente creando un nuovo file eseguibile, ad esempio in /usr/bin:

$ sudo touch /usr/bin/handbook
Parola d'ordine:
$ sudo chmod a+x /usr/bin/handbook

All’interno del file handbook ci sarà lo script bash:

#!/bin/bash

REQUIRED_PAGE=$@

export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
case $TERM in
    xterm)
        export LESS_TERMCAP_us=$'\E[01;34m'
        ;;
    *)
        export LESS_TERMCAP_us=$'\E[01;32m'
        ;;
esac

man $REQUIRED_PAGE
EXIT_STATUS=$?

unset LESS_TERMCAP_mb
unset LESS_TERMCAP_md
unset LESS_TERMCAP_me
unset LESS_TERMCAP_se
unset LESS_TERMCAP_so
unset LESS_TERMCAP_ue
unset LESS_TERMCAP_us

exit $EXIT_STATUS

In questo modo le pagine man colorate saranno accessibili con il comando handbook:

Pagine man colorate con handbook

Approfondimento

Per sapere cosa viene colorato dalle variabili LESS_TERMCAP_xy si deve fare riferimento alla pagine man termcap, al cui interno cercare la spiegazione dei codici mb, md, me, se, so, ue, us. Ad esempio, us indica l’inizio della sottolineatura, mentre ue ne indica la fine.

I valori numerici a due cifre che iniziano con 0, come quello segnato in grassetto in LESS_TERMCAP_so=$’\E[01;44;33m’, permettono di specificare alcune proprietà del testo:

  • 00 = nessuno
  • 01 = grassetto
  • 04 = sottolineato
  • 05 = lampeggiante
  • 07 = rovesciato
  • 08 = nascosto

I valori numerici a due cifre che iniziano con il numero 3, come quello segnato in grassetto in LESS_TERMCAP_so=$’\E[01;44;33m’ colorano il testo:

  • 30 = nero
  • 31 = rosso
  • 32 = verde
  • 33 = giallo
  • 34 = blu
  • 35 = magenta
  • 36 = azzurro
  • 37 = bianco

I valori numerici a due cifre che inizia con 4, come quello segnato in grassetto in LESS_TERMCAP_so=$’\E[01;44;33m’, specificano il colore dello sfondo:

  • 40 = nero
  • 41 = rosso
  • 42 = verde
  • 43 = giallo
  • 44 = blu
  • 45 = magenta
  • 46 = azzurro
  • 47 = bianco

E con questo è tutto.

Velocizzare Firefox

È 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.

Rendere il sistema più fluido

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!

Next »