Pidgin: cancellare i messaggi personali

In fondo alla finestra Lista Contatti di Pidgin è presente un campo testuale per specificare il messaggio di stato (o messaggio personale, o ancora sottonick, nello slang di MSN). Pidgin salva gli ultimi sei messaggi di stato inseriti e li inserisce nel menu a tendina per una scelta rapida.

E’ possibile cancellare i messaggi di stato che si ritiene siano superflui, ma la procedura è tutt’altro che intuitiva: bisogna

1. Portarsi col mouse ad avidenziare il messaggio di stato da cancellare.
2. digitare il tasto CANC
3. Confermare l’eliminazione del messaggio di stato.

Testato con Pidgin 2.6.4.

Digitazione caratteri UNICODE in ambiente GTK

E’ possibile digitare  da tastiera qualsiasi carattere UNICODE nei programmi che fanno uso delle librerie GTK (quindi tutto GNOME, tra le altre cose) usando questa combinazione di tastiera:

CTRL + SHIFT + U

a questo punto comparirà una u sottolineata. Ora bisogna digitare il codice esadecimale del carattere UNICODE desiderato, tipo 03b2 per la lettera β dell’alfabeto greco (che io ho appena digitato usando questo stesso metodo =D ). Il carattere sostituirà la stringa sottolineata u03b2 premendo spazio o invio.

Per conoscere il codice UNICODE del carattere desiderato si può consultare la vecchia, buona mappa caratteri oppure trovare una lista onnicomprensiva.

Backup e Restore del MBR con dd

dd if=/dev/sda of=/home/$whoami/backup_mbr.bin bs=512 count=1

Cambiando la dimensione del settore a 446, escludiamo dal backup la tabella delle partizioni.

dd if=/dev/sda of=/home/$whoami/backup_mbr.bin bs=446 count=1

Il ripristino si ottiene capovolgendo le interfacce di I/O:

dd if=/home/$whoami/backup_mbr.bin of=/dev/sda bs=512 count=1

Per cancellare l’MBR impostiamo come interfaccia di input /dev/zero (azzeramento) o /dev/urandom (riempimento con valori casuali). Con un settore da 446 byte salvaguardiamo la Partition Table.

Embed di video Youtube in HQ

Si aggiunge al classico codice di embed &ap=%2526fmt%3D18 al parametro src del tag embed e al parametro value del primo tag param.

Da cosi:

<object width="425" height="344">
<param name="movie" value="LINK"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed
   src="LINK"
   type="application/x-shockwave-flash"
   allowscriptaccess="always"
   allowfullscreen="true"
   width="425" height="344">
</embed>
</object>
</code>

A cosi:

<object width="425" height="344">
<param name="movie" value="LINK&ap=%2526fmt%3D18"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed
   src="LINK&ap=%2526fmt%3D18"
   type="application/x-shockwave-flash"
   allowscriptaccess="always"
   allowfullscreen="true"
   width="425" height="344">
</embed>
</object>

Con WordPress è sufficiente effettuare l’aggiunta dopo aver messo il normale link nel popup di inserimento video.

mencoder – Hard-coding sottotitoli

mencoder [input file] -o [output file] -oac pcm -ovc lavc -lavcopts vcodec=libx264:vpass=2:vbitrate=1800 -fps 24000/1001 -ofps 24000/1001 -sub [file sottotitolo] -utf8 -subfont [path al font] -subfont-autoscale 1

Dove l’originale è un .mov codificato in H264 con l’audio in MPEG-4 AAC Stereo a 48000 kHz.

Dunque:

-oac pcm

trasforma l’audio in Wave. “copy” non è consentito con l’audio di questo file e “mp3lame” causava uno sfasamento audio/video che non riesco a spiegarmi. “lavc” stessa cosa, usando poi libmp3lame nel parametro acodec.

-ovc lavc

adopera la libreria di codec libavcodec, quella di default e consigliata.

-lavcopts

indica che seguono i parametri di encoding, separati da due punti (o da virgole, credo vadano bene uguale).

vcodec=libx264

codifica il video usando il Codec x264 H.264/AVC MPEG-4 Part 10.

vpass=2

esegue la codifica a doppia passata.

vbitrate=1800

setta il bitrate, credo costante, del video in output espresso in kbit/s.

-fps 24000/1001

specifica il Frame Rate del video di input, ossia 23.976 in questo caso. Se fosse stato 29.97 si sarebbe specificato scritto 30000/1001.

-ofps 24000/1001

stessa cosa, ma determina il FR del video codificato. In questo caso non cambia, quindi presumo che entrambe le opzioni sia inutili.

-sub [file sottotitolo]

specifica il file contente i sottotitoli da renderizzare.

-utf8

informa che i sottotitoli sono in formato Unicode 8. (Dipende, in questo caso lo erano, altrimenti va specificato l’esatto formato pena la comparsa di caratteri assurdi).

-subfont [path al font]

Il font da usare per i sottotitoli, un truetype credo sia il solo ad andar bene.

-subfont-autoscale 1

adatta la dimensione dei sottotitoli in proporzione all’altezza del video. Era l’unica ad andare bene, ma non sono riuscito a capire come specificare l’altezza del font in pixel o punti. Le altri opzioni sono 0 (no autoscale, viene piccolissimo), 2 (in proporzione alla larghezza, troppo grande) e 3 (in proporzione alla diagonale, troppo grande).

Il file di output era 36 MB, ovviamente causa audio PCM. Ricomprimendolo con lamemp3 da mencoder continua a sfasare l’audio. Ricodificandolo in AAC con Avidemux, ottengo un file perfetto di soli 600KB più grande dell’originale.

Trucchetti da manuale

man -k <qualcosa>


Cerca tutte le pagine di manuale che contengano quel qualcosa nella loro descrizione.

Se all’interno di una pagina di manuale si digita

/<qualcosa>

Vengono 1) sottolineate tutte le occorrenze della stringa e 2) digitando di nuovo “/” e premendo invio si naviga in sequenza tra le occorrenze.

Damn Small Sources

We honnor the GPL and will send anybody the sources to the GPL software in Damn Small.
If you want to recive copies of the software please send us $7 (cost of media and shipping)
and we will gladly mail you the sources.

Please send the check to:
Lizard Biscuit
P.O Box 4504
Foster City, CA
94404

Fa piacere vedere cose di cui prima avevi solo letto.

Diplopia

Aggiornamento di sistema in azione su Fedora 9. Modello: PackageKit.

Se usi PackageKit ti accorgi che è una cosetta proprio giovane, ma che se arriverà a fare quello che deve fare bene (ossia permettermi di ignorare tranquillamente la differenza tra deb, yum, apt-get, rpm, synaptic & C.) sarà gioia e delizia del medio utente medio (e a scalare verso il basso, ovvio).

Però io, due finestre per il progress dello stesso task, che si spartiscono le informazioni da visualizzare…. è roba che capita una volta nella vita.

Ah, questi ragazzi. =D

Sala d’attesa

Due link interessanti se si usa Debian unstable (SID).

Li ho scoperti mentre cercavo un modo per risolvere un problema di dipendenze dei repository di SID (il pacchetto gnome-system-tools contemporaneamente dipende e va in conflitto con liboobs-1-3). La soluzione al problema a quanto pare è la pazienza.

Ottimo deterrente:

Incoming. Qui giacciono tutti i pacchetti uploadati e approvati, ma ancora in attesa di essere installati nei repository e mirror Debian. Praticamente si può vedere qui un anteprima di quello che sarà prossimamente disponibile con apt-get.

NEW Queque. Questa è la sezione con le informazioni presenti sui pacchetti NUOVI, ossia quelli che non sono ancora presenti in nessuno dei repo e aspirano ad entrarvi.

Patchare i sorgenti del kernel Linux

» Un po’ di teoria

Le versioni del kernel seguono lo schema 2.6.xx.yy. 2 e 6 denotano rispettivamente la versione del kernel e la sua major revision. Il kernel è alla versione 2 dal 1996 mentre siamo alla major revision numero 6 dal Dicembre del 2003: cambiano molto, molto, molto di rado e solo in seguito a profondi sconvolgimenti del codice.

xx è la cosiddetta minor revision. Viene incrementata ogni volta che viene rilasciato un kernel che presenta nuovi driver e nuove funzionalità: questo avviene all’incirca ogni 2 mesi, secondo l’attuale ciclo di sviluppo.

yy indica invece il livello di bugfix. Le correzioni a bug del kernel, nella fattispecie quelle più urgenti come quelle dei problemi di sicurezza, vengono cumulate e rilasciate a scadenze regolari e ravvicinate, numerandole appunto con il livello di bugfix. Solitamente vengono rilasciati una decina di bugfixes tra due revisioni minori del kernel.

Ad esempio, l’attuale rilascio del kernel è il 2.6.25.4.

Verione 2 del kernel.

Revisione maggiore 6.

Revisione minore numero 25.

4° bugfix della minor revision 25.

» No al download coatto

Sull’archivio ufficiale del kernel Linux sono disponibili degli archivi onnicomprensivi, contenenti cioè tutto il codice del kernel in formato compresso. Questo vale per ogni singolo rilascio: viene reso disponibile un archivio di circa 50 Megabyte.

Tuttavia, tra una major revision del kernel e un suo bugfix spesso cambiano solamente un centinaio di righe di codice, non di più. E le righe di codice del kernel sono milioni.

Quindi, anzichè riscaricare ogni volta il pacchetto completo, si può patchare una minor revision del kernel. Applicare una patch significa scaricare un file di qualche KB che contiene solo le differenze nel codice, e applicare queste piccole modifiche al sorgente originale.

La patch per il kernel più recente è nel link annunciato da “The latest stable version of the Linux kernel is:“

La patch del kernel è applicabile unicamente all’archivio completo del sorgente della sua più recente minor revision. La patch 2.6.25.4 ha bisogno dell’archivio del kernel 2.6.25 per poter essere applicata (si dice cioè che l’archivio in questione è la patch baseline).

L’archivio completo della patch baseline lo trovate linkato alla “B” che si trova sul secondo rigo, quello che recita “The latest prepatch for the stable Linux kernel tree is“.

In violetto la patch, evidenziata la B del kernel completo.

» Scompattare e patchare

Acquisiamo i privilegi di root.

Si scompatta e si spostano i sorgenti completi del kernel. L’ultimo comando crea un link simbolico alla cartella dei sorgenti, permettendoci di riferirci ad essa come “linux”, per semplicità:

#: tar -xvjf linux-2.6.xx.tar.bz2
#: mv linux-2.6.xx /usr/src
#: ln /usr/src/linux-2.6.xx.yy /usr/src/linux

Si scompatta e si sposta la patch

#: tar -xvjf patch-2.6.xx.yy
#: mv patch-2.6.xx.yy /usr/src/linux

Ora ci si sposta nella dir dei sorgenti e si applica la patch

#: cd /usr/src/linux
#: patch -p1 < patch-2.6.xx.yy

pochi secondi e i sorgenti dell’ultrarecentissima versione del kernel sono pronti alla compilazione.

Ma io sono pronto alla compilazione?