In particolare Fedora 12 lamenta l’assenza tra i codec installati di default i plugin necessari al noto engine gstreamer per un po’ tutti i protocolli audio. Per cui ci tocca farlo a mano con (come root):

yum install gstreamer-plugins-ugly gstreamer-plugins-bad-extras gstreamer-plugins-bad-nonfree

Ho trovato questa chicca su come installare su Fedora 12 Constantine il flash-plugin nativo con supporto EM64T.

I passi sono molto semplici e da eseguire naturalmente come root (o mediante sudo):

• Per prima cosa occorre rimuovere ogni installazione a 32 bit di flash (e il nspluginwrapper)

yum erase flash-plugin nspluginwrapper*

• Quindi ci si sposta nella directory dei repository di yum e si scarica il file con le info per il repository del plugin flash a 64bit:

cd /etc/yum.repos.d/

curl -O http://www.dfm.uninsubria.it/compiz/fusion-testing/flashplayer.x86_64/flash.repo

• A questo punto, ovviamente, occorre importare la chiave GPG del repository in questione

rpm –import http://www.dfm.uninsubria.it/compiz/fusion-testing/flashplayer.x86_64/RPM-GPG-KEY-leigh123linux

• ed infine si può finalmente installare il plugin a 64 bit

yum install flash-plugin

Tuttavia, il supporto all’accelerazione 3D, fornito mediante le DRI delle librerie MESA, è disabilitato di default, trattandosi di un supporto ancora sperimentale presente solo nel ramo git 7.6 delle Mesalib.

Ancora una volta, però, il team RedHat ha realizzato un porting del codice in questione attivabile mediante un semplice:

yum install mesa-dri-drivers-experimental

dopo il quale, con un semplice reboot, si ottiene l’agognato supporto all’accelerazione 3D senza la necessità di dipendere dalle stramaledette fglrx.

La semplicità è disarmante!

Basta connettere il cavo USB, e sul telefono andare su Impostazioni->Controlli Wireless e selezionare l’opzione “Condivisione rete mobile”. Immediatamente vedrete l’icona dell’applet di Network Manager animarsi e dopo un paio di secondi mutare nel fatidico disegno dei due PC connessi (vedi figura)…

Ed il pensiero vola alle tribolazioni con i winmodem di qualche anno fa…

Naturalmente è consigliata una Flat decente (io uso la SuperInternet di H3G).

Editate il file (da root)

/etc/sudoers

ed aggiungete la riga

NomeVostroUtente        ALL=(ALL)    NOPASSWD: ALL

salvate e a quel punto potrete eseguire qualsiasi comando tramite sudo senza la necessità di inserire la password di root.

Per cui, per abilitare l’autologin basta editare il file (con i privilegi di root)

/etc/gdm/gdm.schemas

Individuando le sezioni:

<key>daemon/AutomaticLoginEnable</key>
<signature>b</signature>
<default>true</default>            <=== settare a true
</schema>

<schema>
<key>daemon/AutomaticLogin</key>
<signature>s</signature>
<default>NomeUtente</default>    <=== qui mettere il nome utente
</schema>

<schema>
<key>daemon/TimedLoginEnable</key>
<signature>b</signature>
<default>true</default>             <=== settare a true
</schema>

<schema>
<key>daemon/TimedLogin</key>
<signature>s</signature>
<default>NomeUtente</default>    <=== qui mettere il nome utente
</schema>

<schema>
<key>daemon/TimedLoginDelay</key>
<signature>i</signature>
<default>10</default>          <=== Attesa in secondi
</schema>

riavviate et voilà!

PS: Non è propriamente necessario riavviare, basta switchare dal runlevel 5 al 3 e di nuovo indietro al 5 con

init NumeroDelRunlevel

Aldilà della possibilità di realizzare script ad hoc per ogni situazione (in proposito vi suggerisco l’ottima Advanced Bash Scripting Guide), magari da integrare con altri linguaggi di scripting (awk, perl, python…), BAsh ha una versatilità incredibile quando si tratta di accorpare in un’unica soluzione, più operazioni, mediante l’utilizzo di pipe o reindirizzamento dell’input/output standard.

La presenza poi della cosiddetta “history” permette di recuperare queste lunghe sequenze anche a distanza di tempo, senza perciò la necessità di dover ricordare o appuntare da qualche parte l’intera sequenza.

Navigare in questa history è abbastanza semplice… si possono usare le freccette (su e giù) per scorrere avanti ed indietro, oppure cercare un comando specifico premendo <CTRL + r>, ecc ecc

Un limite piuttosto grosso, tuttavia, è legato al comportamento standard di non “catturare” nella history del terminale attualmente in uso, i comandi digitati su un altro terminale. Questo porta ad una estrema frammentarietà della funzione di history, e ne limita, a mio avviso, enormemente le potenzialità.

Esiste però un accorgimento (documentato per altro nella sconfinata guida di BAsh), che permette di ovviare a tale situazione! Si tratta di editare il file

gedit ~/.bashrc

ed aggiungere le seguenti linee:

shopt -s histappend

PROMPT_COMMAND=’history -a’

che permetteranno l’append incrociato di comandi all’history della shell, tra i vari terminali aperti. Ovviamente per abilitarro dovrete riloggarvi in ciascun terminale aperto oppure fare il source.

Un’altra interessante funzione è una sorta di “correttore automatico” molto simile alla funzione di autocompletamente (tasto TAB), che ci viene in aiuto quando “navighiamo” per le cartelle. L’opzione da aggiungere, sempre al medesimo file, stavolta è:

shopt -s cdspell

Continuando a parlare di hsitory, personalmente trovo molto noioso, nello scorrere la lista dei comandi, le continue ripetizioni di comandi spesso semplici e banali, quali i cambi directory o i vari copy e move. Per eliminare le ripetizioni, basta un bel:

export HISTIGNORE=”&:ls:[bf]g:exit”

Questi ed altri trucchi li potete trovare nel manuale di BAsh.

fonte: TuxJournal

Sono riuscito a sistemare temporaneamente la cosa andando ad editare a mano /usr/bin/startx, ed inserendo tra le opzioni di lancio “-ignoreABI“, e così a mano Xorg parte con i driver Nvidia! Ma manca ancora l’accelerazione 3D, infatti se provo a lanciare da gnome-terminal un bel

glxinfo

ottengo come risposta un errore di incompatibilità con le Xlib…

Piano piano i nodi stanno venendo al pettine!

Non tutti lo sanno, ma Firefox, per scelta del suo team, non ha un sistema di autenticazione automatico sui Proxy autenticati, cosa che ci obbliga ad inserire manualmente username e password di autenticazione ad ogni sessione (è tuttavia possibile memorizzarle nel suo keyring, ma cmq è indispensabile premere “ok” nell’apposita finestra che ci si apre ad ogni nuova sessione).

Nell’azienda in cui lavoro ho un proxy server con autenticazione che costituisce percorso obbligato per uscire sulla rete internet, ed ho scoperto, mio malgrado, che sulla mia nuova Fedora 8, Miro non era in grado di procedere all’autenticazione sullo stesso, sebbene i parametri di configurazione proxy di gconf fossero correttamente inseriti nell’apposita sezione del menù di Sistema.

Dal log risultava infatti che Miro, correttamente, leggeva il valore “nome_proxy” dall’apposita voce gconf, ma non era in grado di gestire l’autenticazione, non potendo così connettersi all’esterno.

Come in ogni buon fumetto, mi si accende immediatamente una lampadina… e se provassi ad utilizzare un proxy locale per autenticare, e far passare le connessioni di tutti quei software che non gestiscono al meglio l’autenticazione proxy, attraverso esso?

Detto fatto… installo e configuro con un paio di regole minimali squid, ed aggiungo la seguente riga che abilità il “chaining” dei proxy:

cache_peer NOMEPROXY.DOMINIO parent PORTAPROXY 3130 no-query proxy-only default login=USERNAME:PASSWORD

Ma veniamo a spiegare le varie opzioni:

• cache_peer: è l’istruzione che abilita il peering, cioè il collegamento tra cache dei proxy
• NOMEPROXY.DOMINIO: ovviamente è l’indirizzo del proxy con autenticazione
• parent: indica a squid che si tratta di un proxy che ha un ordine gerarchico superiore
• PORTAPROXY: vabbè… devo spiegarvelo?
• 3120: è la porta su cui inoltrare i comandi del protocollo proxy… lasciatela com’è tanto non interfacceremo i due proxy.
• no-query proxy-only: queste due opzioni dicono a squid di comportarsi semplicemente come intermediario… in pratica non negozia alcun tipo di sincronizzazione della cache con il server proxy reale, si limita a passargli le richieste di connessione locali e riceverne i risultati.
• default: in unione a parent, serve a descrivere la topologia gerarchica… in pratica per ogni oggetto no presente nella cache locale, si farà una richiesta al genitore (parent) piuttosto che avviare una connessione diretta.
• login=USERNAME:PASSWORD vabbè… di nuovo,,, ve lo devo commentare…

A questo punto non vi resta che riavviare squid e… magia… ecco Miro bello che pronto all’uso!

Ricordo alla mia prima installazione di gentoo… sistema + kde + firefox + thunderbird, ci volle quasi una settimana sul mio vecchio Athlon XP 1800+, già con il passaggio al pentium 4 in una giornata scarsa il sistema era bello che pronto ed aggiornato… Adesso con sistemi dual/quad core i tempi sono scalati ulteriormente…

Tuttavia, pur aumentando la prestazioni della cpu, il tempo di compilazione non scala linearmente, colpa di una serie di colli di bottiglia. Essenzialmente in un sistema che scarica da un qualsiasi repository i sorgenti per poi compilarli ci sono due colli di bottiglia: la connessione ed il filesystem.

Dei due, il primo (problema) è endemico… l’unica è avere una connessione veloce… si può migliorare la cosa utilizzando, magari, dei gestori di download, ma se volete il sistema sempre aggiornato all’ultima versione presente sul repository vi dovete rassegnare e portare pazienza… (io per fortuna ho fastweb che sulla rete GARR va da Dio! ).

Quello del filesystem invece è un problema più facilmente gestibile…

Il collo di bottiglia, in questo caso, consta nello spostamento dei dati da e verso il disco nella RAM. Quindi l’ideale sarebbe poter scaricare i sorgenti direttamente in RAM e compilarli da lì… nulla di più facile: quello che ci occorre è un ramdisk. Ovviamente, per utilizzare questo sistema dovrete avere un generoso quantitativo di RAM, per poterne dedicare una porzione di dimensioni adeguate alla dimensione dei sorgenti che volete compilare… Inoltre dovete ricordarvi che la RAM è una memoria volatile, per cui, se per qualche motivo volete conservare sorgenti e file di configurazione, dovrete ricordarvi di trasferirli sul disco fisso, prima di smontare il ramdisk/spegnere il computer, pena la perdita irreparabile di quanto contenuto in esso.

Ma andiamo con ordine…

Quello che vi serve è il supporto ai ramdisk compilato nel kernel o come modulo… la maggior parte dei kernel ha tale supporto anche perchè, in fase di avvio, di solito, montano un ramdisk per caricare i moduli di cui hanno bisogno prim’ancora di aver potuto montare il rfs (ad esempio i moduli del controller dei dischi). Se questo è il vostro caso, allora si tratta semplicemente di andare ad editare il file di configurazione del vostro boot loader (grub o lilo) ed aggiungere tra i parametri da passare al kernel l’opzione:

ramdisk_size=SizeInKbytes

Una volta rebootato il sistema vi dovreste ritrovare almeno un device /dev/ramX, dove X è un numero… che potrete montare come un qualsiasi disco previa formattazione con

mkfs -t ext2 /dev/ramX

Adesso il disco è bello che pronto per i vostri esperimenti… rimane ancora però da discutere la questione dimensioni. Per determinare la dimensione del ramdisk utile allo scopo dovrete stimare la dimensione dei sorgenti e tenervi un buon margine per i prodotti di compilazione… diciamo che, mediamente, vi serve dal 40 al 50% di spazio in più per ospitare file oggetto, librerie ed eseguibili una volta compilati. Dovete però tener conto che per non penalizzare troppo il sistema, converebbe non eccedere con l’uso della RAM dedicata a ramdisk, per cui, in linea teorica (o come direbbe un mio vecchio prof dell’università, usando il metodo “spannometrico”), per il sistema servono sempre almeno quei 600-700 Mbytes di RAM puliti puliti per girare senza troppi intoppi… da cui ne viene che su un sistema con 1GB di RAM non si dovrebbe superare mai il limite ragionevole di 256MBytes.

Certo, 256Mbytes sono pochi per compilare, ad esempio, tutto KDE, allora la soluzione migliore è compilare a pezzi modulo per modulo, eventualmente swappando poi sul disco tra sorgenti ancora da compilare e moduli già compilati.

Questo ovviamente a meno di non avere un quantitativo spropositato di RAM (che nel 1990 era 4Mbytes, nel 2000 256 Mbytes, nel 2007 è… boh? 4Gigabytes?), nel qual caso potrete divertirvi con le dimensioni che più vi aggradano…