Migliorare il log di git

Filipe Kiss ha pubblicato un ottimo suggerimento per migliorare l’aspetto di git log.

L’aspetto tipico di git log è piuttosto noioso:

È possibile rendere più leggibile il log, ottenendo qualcosa come questo:

Per farlo, è sufficiente eseguire:

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit

Visto che è un po’ lungo da digitare, può convenire creare un alias, ad esempio chiamarlo git lg:

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit"

È anche possibile eseguire git lg -p per visualizzare il diff dei commit, anche questi con syntax highlighting.

Come copiare testo da terminale agli appunti di X

A volte è necessario o comodo copiare del testo dal terminale agli appunti (clipboard) di X – ad esempio per incollare il testo su una chat o forum con un semplice CTRL+V. Si può fare facilmente con il programma xclip. Per installarlo su Debian, Ubuntu e derivate, bisogna eseguire:

sudo aptitude install xclip

Il suo utilizzo e molto semplice: basta mandare in pipe a xclip il testo che si desidera. Ad esempio per copiare le informazioni relative a dhclient presenti nei log, si può eseguire:

grep dhclient /var/log/syslog | xclip -selection c

In questo modo tutte le linee in /var/log/syslog contenenti dhclient vengono copiate negli appunti e possono essere incollate con CTRL+V.

Monitoraggio delle performance del kernel Linux giorno per giorno

Phoronix ha lanciato un progetto per cui ogni giorno viene automaticamente scaricata e compilata l’ultima versione del kernel Linux disponibile e vengono eseguiti i benchmark del Phoronix Test Suite. I risultati vengono pubblicati su phoromatic.com. È un progetto interessante che permette di monitorare facilmente i progressi nelle performance del kernel. Un esempio dei grafici disponibili è il seguente:

In cui vengono mostrati il numero di secondi necessari per effettuare un encoding di un file audio da WAV a FLAC. I risultati mostrati sono relativi all’ultimo mese di sviluppo del kernel, che incidentalmente coincide con il completamento della release 2.6.33.

Phoromatic è un progetto piuttosto interessante, vale la pena di perderci qualche minuto a settimana per tenere d’occhio cosa combinano gli sviluppatori da un punto di vista sensibile per l’utente finale. I risultati dei test sono disponibili all’indirizzo http://www.phoromatic.com.

Accelerare Firefox 3 ripulendo il suo database

Firefox icon by everaldo.comCon Firefox 3.0 è stata introdotta la “Awesome Bar”: la barra degli indirizzi intelligente che può essere utilizzata come navigatore della cronologia.

Questa funzionalità fa un uso piuttosto intenso dei database intensi di Firefox, e con il tempo può diventare piuttosto lenta. È possibile però “ripulire” il database per ritornare ad avere buone performance. Per farlo:

  1. Dal menu Tools (Strumenti) selezionate Error Console (Console degli errori)
  2. Nella casella Code (Codice) inserite la seguente istruzione su un unico rigo:
    Components.classes["@mozilla.org/browser/nav-history-service;1"].getService(Components.interfaces.nsPIPlacesDatabase).DBConnection.executeSimpleSQL("VACUUM");
  3. Cliccate su Evaluate (Valuta): l’interfaccia grafica si bloccherà per alcuni secondi mentre i database di Firefox vengono riorganizzati.

Al termine dell’operazione la awesome bar di Firefox dovrebbe tornare ad avere buone prestazioni.

Sulla lunghezza delle chiavi negli algoritmi crittografici simmetrici

EncryptedOggi Bruce Schneier ha pubblicato un brano tratto dal suo Applied Criptography. L’occasione è il debunking di un bizzarro algoritmo crittografico simmetrico che usa chiavi da 49152 bit — segno piuttosto chiaro che gli autori dell’algoritmo non hanno esattamente in mente di cosa stiano parlando. Mi permetto di riportare qui il brano correggendo i dati numerici e modificando leggermente gli esempi.

Una delle conseguenze del secondo principio della termodinamica — osserva Schneier — è che è necessaria una certa quantità di energia per rappresentare l’informazione. Memorizzare un singolo bit cambiando lo stato di un sistema richiede una quantità di energia pari almeno a kT, dove k è la costante di Boltzmann e T è la temperatura assoluta del sistema.

Dato che k = 1.38065 × 10-23 J/K e che la temperatura dell’universo è di 2.725 K, un computer ideale funzionante a 2.725 K consumerebbe 3.7623 × 10-23 J per impostare un bit a 0 o 1. Per far funzionare il computer a una temperatura ancora più bassa servirebbe dell’energia aggiuntiva per far funzionare una pompa di calore.

Il nostro Sole emette ogni anno circa 1.22 × 1034 J, che è il necessario per far 3.2427×1056 cambi di bit sul computer ideale, vale a dire per far ciclare attraverso tutti i suoi valori un contatore da 187 bit. Se costruissimo una sfera di Dyson (un’ipotetica megastruttura che cattura tutta l’energia di una stella) attorno al nostro Sole basterebbero 32 anni per poter contare fino a 2192. Ovviamente non rimarrebbe energia per poter elaborare in alcun modo questi valori.

Un piccolo ammasso globulare, cioè una specie di mini-galassia che orbita attorno a una galassia maggiore, può avere una massa di 5.5 × 1037 kg. Se annichilissimo tutta la materia dell’ammasso con un pari quantitativo di antimateria come conseguenza del famoso E=mc2 otterremmo 2 × 1053 J, poco più del necessario per far ciclare completamente un contatore da 256 bit.

Questi numeri non hanno nulla a che fare con la tecnologia dei computer: sono il massimo che la termodinamica permette. Questo vuol dire che gli attacchi di forza bruta contro chiavi da 256 bit saranno computazionalmente insostenibile fino a quando i computer non saranno fatti di qualcosa di diverso dalla materia e occuperanno qualcosa di diverso dallo spazio.

Una leggenda metropolitana piuttosto diffusa vuole che i mitici computer quantistici polverizzeranno senza problemi le chiavi degli algoritmi crittografici simmetrici “provando tutte le chiavi contemporaneamente”. In realtà nel 1996 Bennet, Bernstein Brassard e Vazirani hanno dimostrato che un attacco di forza bruta su un algoritmo simmetrico non può richiedere meno di 2n/2 invocazioni dell’algoritmo stesso, dimezzando quindi lo spazio delle chiavi da esplorare. Un algoritmo con chiave da 256 bit offre dunque una resistenza a un ipotetico computer quantistico di almeno 128 bit (link al paper).

Gli attacchi agli algoritmi di crittografia mirano quindi a ridurre drasticamente lo spazio di ricerca in modo intelligente, dato che lo spazio di tutte le chiavi possibili è un problema fisicamente inaffrontabile.

Ha ben ragione Schneier quando mette tra le caratteristiche per individuare la crittografia farlocca “ridiculus key lengths”: chi propone algoritmi con chiavi da 49152 bit o addirittura 1 milione probabilmente ha le idee un po’ confuse.

Usare SSH come server proxy

Web icon by everaldo.comPuò capitare che si disponga di un server a cui si dispone di accesso via SSH e si desideri utilizzarlo come server proxy per la navigazione sul web.

Il client SSH rende semplice questa operazione: permette di mettere in ascolto sulla macchina locale un server proxy SOCKS che rigirerà al server remoto tutte le richieste di connessione all’interno del “tunnel” SSH.

Supponendo di voler mettere in ascolto sulla porta locale 8080 il server proxy, che la macchina remota abbia IP 10.0.0.1 e che il nome utente remoto sia mrossi il comando da lanciare è:

ssh -D 8080 -Nf mrossi@10.0.0.1

(se il nome utente attuale è uguale a quello sulla macchina remota si può tralasciare la stringa mrossi@).

Una breve spiegazione degli switch utilizzati con SSH:

  • -D 8080: indica la volontà di creare un proxy SOCKS in ascolto sulla porta 8080 sull’indirizzo di loopback (127.0.0.1). Opzionalmente si può specificare qualunque indirizzo locale su cui mettersi in ascolto;
  • -N: indica a SSH che non si desidera eseguire alcun comando;
  • -f: fa sì che subito dopo l’autenticazione SSH vada in background.

Una volta eseguito il comando si può configurare il proprio browser per utilizzare il proxy SOCKS in ascolto su 127.0.0.1:8080. Se il vostro browser è Firefox potete utilizzare FoxyProxy per gestire facilmente i proxy.

Chi sta accedendo al disco? Monitorare l’uso dell’I/O.

HardDisk icon by everaldo.com Una feature molto comoda del task manager di Windows è quella che permette di visualizzare quali processi stanno scrivendo su disco e in quale misura. È possibile ottenere queste informazioni anche su Linux. Un metodo rapido per ottenere un’informazione del genere è eseguire da root:

echo 1 > /proc/sys/vm/block_dump

Eseguendo dmesg sarà possibile avere un colpo d’occhio di quali processi stiano effettuando burst di scritture, con un output simile a questo:

[  409.805443] firefox-bin(4288): WRITE block 25335048 on sda7
[  409.805468] firefox-bin(4288): WRITE block 25335112 on sda7
[  409.805493] firefox-bin(4288): WRITE block 25335136 on sda7
[  409.805520] firefox-bin(4288): WRITE block 25335176 on sda7
[  409.805589] kjournald2(729): WRITE block 17053608 on sda7
[  409.805608] kjournald2(729): WRITE block 17053616 on sda7
[  409.805620] kjournald2(729): WRITE block 17053624 on sda7
[  409.805631] kjournald2(729): WRITE block 17053632 on sda7
[  409.805642] kjournald2(729): WRITE block 17053640 on sda7
[  409.810454] kjournald2(729): WRITE block 17053648 on sda7
[  409.963898] firefox-bin(4288): dirtied inode 3198 (places.sqlite-journal) on sda7
[  410.004105] pdflush(23): WRITE block 16922864 on sda7
[  410.004257] pdflush(23): dirtied inode 10220 (plasma_theme_default.data) on sda7
[  410.004291] pdflush(23): WRITE block 36789872 on sda7
[  410.004310] pdflush(23): WRITE block 36789880 on sda7

Piccola nota: pdflush è il demone che si occupa di scrivere su disco le scritture rinviate dal kernel per motivi di performance, kjournald(2) si occupa di mantenere aggiornato il journal del filesystem ed è normale che siano spesso presenti. Questo output tuttavia non è di comoda lettura. Una alternativa è data dal software iotop, installabile con Synaptic, aptitude o il packet manager della distribuzione che preferite. Avviandolo con:

iotop -o

Si otterrà un output di questo tipo:
che mostra i quattro processi che hanno effettuato operazioni di I/O nel periodo di campionamento. In questo caso sono il già citato pdflush e wget che hanno effettuato delle scritture, mentre svn ha effettuato una lettura.

Le colonne di iotop mostrano nell’ordine:

  • il PID del processo;
  • la velocità di lettura nel periodo di campionamento (di default 1 secondo);
  • la velocità di scrittura nel periodo di campionamento;
  • il tempo impiegato per lo swapping;
  • il tempo atteso per l’accesso all’I/O;
  • il nome del processo e i suoi argomenti.

Il manuale di iotop indica gli switch utili per un uso più mirato di questo ottimo strumento.

Nuovi hash cercasi

Il primo Novembre è terminata la prima fase del concorso indetto dal Natiolan Institute of Standards and Technology (NIST). È scaduto infatti il termine entro il quale presentare proposte di algoritmi di hashing per sostituire lo scricchiolante SHA-1 e creare il nuovo SHA-3. Non sono disponibili dati sul numero di “concorrenti”, ma si suppone che siano tra i 30 e i 50. Mentre scrivo sono disponibili le descrizioni di 20 algoritmi sul wiki dell’Institut für Angewandte Informationsverarbeitung und Kommunikation (IAIK, Institute for Applied Information Processing and Communications) dell’università tecnica di Graz.

Il concorso è stato indetto dal NIST nel 2007, per designare il successore dell’algoritmo di hashing SHA-1, ritenuto poco sicuro soprattutto a causa dell’attacco studiato da Xiaoyun Wang (王小云), che permette di trovare una collisione con 263 operazioni, contro le 280 operazioni che sarebbero necessarie. Il successore attuale di SHA-1 è SHA-2 e la sua famiglia (SHA-224, SHA-256, SHA-384 e SHA-512). Gli hash di SHA-2 sono però dello stesso tipo di SHA-1, per cui la comunità crittografica non ritiene saggio fidarsi sul lungo periodo di tali algoritmi. Per questo motivo si è deciso di creare il nuovo SHA-3, che dovrebbe essere annunciato nel 2012.

Tra le proposte più discusse c’è Skein, creato da Bruce Schneier – co-sviluppatore di Twofish – insieme a universitari e sviluppatori di Intel e Microsoft. L’algoritmo è estremamente veloce (500MiB/sec per core su un Core 2 Duo x64 3.1 GHz, veloce il triplo di SHA-512 e quasi il doppio di SHA-256) e snello (è possibile implementare Skein-512 con 200 byte di stato e Skein-256 con soli 100 byte), e utilizza primitive simili a quelle usate da SHA-2.

Degno di nota è anche MD6, sviluppato da un team del MIT guidato da Ron L. Rivest, noto per essere stato co-autore di RSA, MD4, MD5 e RC6 (uno degli algoritmi finalisti per lo standard AES). MD6 ha un design tradizionale, è relativamente lento (che può non essere solo uno svantaggio per un algoritmo di hashing) e è studiato per funzionare bene su sistemi paralleli.

La squadra Danese e Austriaca che ha progettato Serpent (finalista AES) e trovato vulnerabilità in SHA-1 e GOST ha inviato come proposta Grøstl, la cui architettura si discosta nettamente da quella di SHA, pur rimanendo veloce come SHA-2. Ci si attende una proposta anche da Joan Daemen e Vincent Rijmen, creatori di Rijndael (vincitore di AES), ma non sono ancora disponibili informazioni a riguardo.

Molte proposte sembrano di sviluppatori amatoriali. L’algoritmo WaMM è stato dimostrato vulnerabile in meno di 24 ore. Geoffrey Park, seguendo le idee di Stephen Wolfram, ha sviluppato un hash, NKS2D, interamente basato sugli automi cellulari, ma è inevitabilmente lento e non è possibile dimostrarne formalmente la sicurezza.

Non sono noti i criteri con cui verrà selezionao il vincitore. Il prossimo passo è la “SHA-3 Candidate Conference” che verrà tenuta a Febbraio 2009.

Pimp My MPlayer

MPlayer è il player per video che uso di più in assoluto. Non è amichevole come Kaffeine o VLC, ma fa benissimo il suo lavoro. Martin Ankerl ha pubblicato sul suo blog un po’ di trucchi per personalizzare MPlayer. Riporto qui quelli che ho trovato più interessanti:

Evitare i salti

Se la CPU è sotto sforzo, il video di MPlayer potrebbe non essere fluido. La situazione è segnalata da questo messaggio:

Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied
Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts.

Per risolvere il problema si può eseguire da una console di root (ottenuta con sudo -i su Ubuntu e derivate o con su su altre distribuzioni):

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

o, per mantenere permanentemente l’impostazione, modificate il file /etc/sysctl.conf e aggiungete questa riga:

dev.rtc.max-user-freq=1024

dopodiché eseguite:

sudo sysctl -p

o riavviate per usare le nuove impostazioni.

Streaming fluido

Guardando video in streaming o da DVD può capitare che il playback salti. Per rimediare si può istruire MPlayer affinché mantenga una cache più grande per il buffering. Modificate il file ~/.mplayer/config e aggiungete le seguenti righe:

cache=8192
cache-min=4

La prima riga specifica un buffer di 8MiB, la seconda indica a MPlayer che il buffer deve essere pieno almeno al 4% (circa 327KiB) prima di eseguire la riproduzione dello stream audio/video.

Output video

Usate xv come output video, è quello che permette una visualizzazione a schermo più veloce. Per farlo aggiungete al file ~/.mplayer/config:

vo=xv

Se non dovesse funzionare provate vo=gl2 oppure, se avete una scheda ATI con driver proprietari fglrx, fate riferimento a questo mio post: Problemi con MPlayer e ATI.

Aspect ratio

Se avete un monitor 16:10 aggiungete al solito file di configurazione la riga

monitoraspect=16:10

anche se in genere non dovrebbe essercene bisogno e MPlayer dovrebbe individuare correttamente l’aspect ratio del monitor.

Volume troppo alto o troppo basso

Si può fare in modo che MPlayer normalizzi il volume dello stream audio, utile quando la traccia è troppo bassa o troppo alta. Per farlo aggiungere a ~/.mplayer/config la riga:

af=volnorm

Font dei sottotitoli

Per cambiare il font dei sottotitoli, copiate il file .ttf del font che desiderate in ~/.mplayer/subfont.ttf. Ad esempio per usare DejaVu Sans eseguite:

cp /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf ~/.mplayer/config

Dimensione dei sottotitoli

Per cambiare la dimensione dei sottotitoli modificate ~/.mplayer/subfont.ttf aggiungendo:

subfont-text-scale=3

Provate valori diversi per trovare l’impostazione più di vostro gusto.

Tasti rapidi

Per l’uso comune:

  • f: attiva/disattiva la modalità fullscreen
  • ESC,q: termina MPlayer
  • barra spaziatrice,p: mette in pausa/riattiva il playback
  • j: cicla tra i sottotitoli
  • o: mostra/nasconde l’OSD (On Screen Display) con la posizione corrente
  • +,-: anticipa/ritarda lo stream audio rispetto al video, utile nei filmati con audio non in sync
  • [,]: diminuisce/aumenta la velocità di playback

Per spostarsi nello stream:

  • sinistra: indietro di 10 secondi
  • destra: avanti di 10 secondi
  • su: avanti di un minuto
  • giù: indietro di un minuto
  • PgUp (o Pag Su): avanti di 10 minuti
  • PgDn (o Pag Giù): indietro di 10 minuti
  • .: avanti di un frame (p per tornare al playback normale)

Twitter da bash

Usate Twitter e da bravi nerd/geek volete utilizzarlo direttamente da bash? Ecco uno script che usa cURL:

#!/bin/bash
#
# Twitter Update
#
# Requires: cURL http://curl.haxx.se/
# By Guillermo Antonio Amaral Bastidas < gamaral@guillermoamaral.com >
#

### CONFIGURE ###

declare -rx USERNAME="YOUR_USERNAME"
declare -rx PASSWORD="YOUR_PASSWORD"

### DONT MODIFY ###

declare -x STATUS="$@"

curl 'http://twitter.com/statuses/update.xml' \
    -u ${USERNAME}:${PASSWORD} \
    -d "status=${STATUS}" > /dev/null 2> /dev/null

# EOF

Inserite il vostro nome utente e password nelle apposite variabili, rendetelo eseguibile con chmod u+x twitter.sh e usatelo:

./twitter.sh Frase da inviare a twitter

Uso perverso:

PROMPT_COMMAND='/path/di/twitter.sh $(history | tail -n 1)'

così potrete davvero far sapere cosa state facendo in questo momento! (Attenzione: era un geek joke, se lo capite vuol dire che ora di fare una passeggiata fuori).