Random Bullshit

Sto leggendo con un certo piacere sadico i post delle persone che s'incazzano per il recente botto di uno degli storage di Tophost.

Perché piacere sadico? Perché il 99.9999% delle lamentele proviene da persone che non hanno MAI effettuato un backup del proprio sito e il restante 0.0001% da persone che pretendono di ottenere con €8.99+IVA all'anno anche un backup giornaliero. Magari su Tivoli Storage Manager¹, già che ci siamo.

¹ Seeweb fa pagare un backup bisettimanale su TSM €475+IVA all'anno per una singola macchina. Non so quante macchine abbia Tophost per i clienti, ma ho come la sensazione che i costi complessivi siano proibitivi rispetto ai loro prezzi (senza contare che il ripristino di un singolo sito da un backup su TSM è un po', come dire… complesso).

La nuova versione di BootCamp include un driver HFS+ per Windows. Siccome ho moderatamente paura di lasciar accedere tale accozzaglia di bug (Windows, ovviamente) al mirror della partizione OSX principale ho pensato "bene" di rimuovere la lettera di unità alla partizione.

Ecco, non fatelo, perché quella fetenzia per andare sul sicuro cambierà il tipo della partizione da Apple HFS/HFS+ a Microsoft Basic Data e ripristinare il tipo corretto è molto, molto, molto complicato (a meno di non usare cose come gptfdisk, ma non lo consiglio ai deboli di cuore).

10 consigli sparsi per il sysadmin che dopo svariati anni alle prese con Debian (qualcuno usa gentoo in produzione? <g>) si trova a combattere con FreeBSD:

1. ZFS è buono, ZFS è bello, ZFS è tuo amico;
2. …purchè la macchina abbia almeno 2 GB di memoria fisica (1 GB se sai mettere mano a vm.kmem_size e compari e l'I/O load non è particolarmente elevato);
3. se hai un po' di fegato e tempo da perdere puoi installare l'OS su ZFS, altrimenti non pensarci e continua ad usare UFS;
4. portsnap evita ulcere, cvsup le causa;
5. make config-recursive è cosa buona e giusta;
6. portupgrade ha delle dipendenze ignobili, ma è una mano santa;
7. ezjail usato con ZFS è una goduria;
8. xntpd e le jail non vanno proprio d'accordo, meglio OpenNTPD;
9. freebsd-update ti toglie la scusa del tempo da perdere libero per via di make buildworld ma evita parecchie rotture di palle;
10. last but not least, RTFM. Sempre e comunque.

Mercurial è indubbiamente uno dei migliori DVCS attualmente in circolazione, è semplice da usare, si integra bene con i miei tool preferiti (fondamentalmente TextMate) ed è scritto in Python.

Ha un'unica pecca: la gui integrata (hgk) è una versione ridotta all'osso di gitk.
E qui entra in scena Murky.

Murky è un piccolo gioiello scritto in Objective-C che permette non solo di navigare comodamente il revision tree di un repository, ma anche gestirlo con pochi click (ad esempio eseguire push & pull, aggiornare la working directory, clonare repository, crearne nuovi, ecc. ecc.). L'interfaccia è molto pulita: da una semplice occhiata è possibile vedere qual è il branch attivo, come sono distribuiti i vari fork e selezionando una revisione è possibile vedere quali file sono stati modificati all'interno di quella revisione (oltre al revision log).

Murky in azione

Se proprio vogliamo essere pignoli, l'unica pecca è l'assenza di feature avanzate come bundle/unbundle, import/export e outgoing/incoming, ma dato che il progetto è opensource (BSD license!) ed è solo alla versione 0.7.1 con molta probabilità verranno aggiunte nelle prossime release (oppure potete metterci mano da soli :P).

PS: astenersi da flame "git VS mercurial", "python VS ruby", "$editor VS TextMate", "osx VS $os", "xin VS tutti".

Mi ero un po' rotto le scatole di Serendipity, quindi ho deciso all'unanimità di sostituirlo con wordpress.
C'è da aspettarsi un po' di casino (vecchi link sputtanati, commenti totalmente persi – complimenti all'autore di serendipity… – Facebook che reimporta i vecchi post, ecc. ecc.), ma prima o poi tutto si stabilizzerà.

Forse…

Tratto dalle frasi di Bertolaso riportate da ilCapoluogo.it, la dimensione è direttamente proporzionale alla frequenza di una parola (al solito, cliccate per ingrandire):

Image made with Wordle.

Come promesso, ecco gli orrendi sorgenti dell'applicazione che ho usato per generare l'elenco dei codici fiscali duplicati (che non ho pubblicato – rompipalle sì, aspirante suicida ancora no) e il grafico "semianonimo" delle relazioni tra duplicati.

Riporto il contenuto del README per maggiore chiarezza:

*******************************************
* Graduatorie alloggi - Ricerca duplicati *
*******************************************

======= NOTA =======
I PDF contenenti gli elenchi sono stati scaricati da ilCapoluogo.it il
20-09-2009 tra le 15:40 e le 15:49, siete liberi di sostituirli con eventuali
elenchi aggiornati ma NON vi garantisco che questo coso continui a funzionare.
Se li sostituite, aggiornate il Makefile.

======= DISCLAIMER =======
I DATI PRODOTTI DA QUESTO SOFTWARE NON HANNO IL MINIMO VALORE LEGALE.
ZERO. NADA. NISBA.
Toglietevi subito dalla testa di usarlo per fare esposti, denunce o simili.
Ricontrollate SEMPRE *SEMPRE* _*SEMPRE*_ i dati prodotti dal software
confrontandoli manualmente con gli elenchi in PDF.
NON MI ASSUMO NESSUNA RESPONSABILITA` IN CASO DI DANNI A
PERSONE/COSE/ANIMALI/AMMINISTRATORI/COMMISSARI STRAORDINARI DERIVANTI DALL'USO
PROPRIO O IMPROPRIO DI QUESTO SOFTWARE.
Se il software tira fuori il vostro nome/codice fiscale: CAZZI VOSTRI!
Gli elenchi sono pubblici (Albo Pretorio del Comune) e nessuno vi ha accusato di
alcunche', risultate solo come duplicati nelle domande.
Se questo vi comporta noia - ripeto - CAZZI VOSTRI!

======= REQUISITI DI SISTEMA =======
  * Bash (cio` implica un sistema *NIX, non garantisco nulla per cygwin)
  * GNU Make
  * GNU Grep
  * Python >=2.5 ma NON 3.x
  * python-lxml
  * python-yapgvb
  * poppler (poppler-utils su debian/ubuntu)

======= UTILIZZO =======
Digitate 'make'. Tutto qui.
Otterrete due file interessanti:
  * duplicati.txt: l'elenco dei codici fiscali duplicati e relativi
    intestatari delle domande a cui appartengono;
  * duplicati.svg: il diagramma "semianonimo" con i grafi delle relazioni tra
    duplicati.

Se volete deanonimizzare il grafo, modificate duplicati.py.
Se non sapete come farlo, attaccatevi.

 -- 21 Sett. 2009, Matteo Panella

Di come vanno le cose per le C.A.S.E. e per i MAP – onestamente – non me ne dovrebbe fregare più di tanto, ho il garage agibile e vivrò lì finchè non avrò finito i lavori a casa.
Però dopo aver letto le dichiarazioni di Fabio Pelini (PRC-SE), mi sono preso la briga di post-elaborare anche io le graduatorie (con un metodo complicato – prima o poi posterò il software che ho scritto e usato) "per vedere l'effetto che fa".

Intanto cominciamo subito con un paio di perle d'annata: il signor D'AL√≤ (sì, avete letto bene: "D'AL-RADICEQUADRATA-MINOREUGUALE") e un certo signor "MARTINELLI" privo di nome e con un codice fiscale che non ha nulla a che vedere con quel cognome.
Ma questo non è niente: il risultato di questa analisi artigianale è che su 23073 codici fiscali OTTANTASEI sono duplicati!

Ebbene sì, c'è gente che compare in più nuclei familiari, oppure ha presentato una domanda ma si trova nel nucleo familiare di un'altra domanda o addirittura ha presentato due domande. Il caso più eclatante è di due intestatari di una domanda, entrambi beneficiari di un alloggio presso le C.A.S.E.: uno figura nel nucleo familiare dell'altro e viceversa!

Non ci credete? Ho preparato un diagramma in SVG che illustra in forma di grafi i "duplicati" e le relazioni che intercorrono tra loro.
I rettangoli rappresentano gli intestatari delle domande, le ellissi le persone che figurano solo come componenti di nuclei, gli archi uscenti da un nodo indicano l'appartenenza al nucleo familiare di una domanda ed i colori indicano la graduatoria in cui è presente l'intestatario:

1. Rosso → beneficiario C.A.S.E.
2. Blu → beneficiario MAP
3. Ciano → in attesa di collocazione
4. Verde → non beneficiario

Nel caso di domande multiple, il colore indica la domanda con assegnazione "maggiore" (secondo l'ordine dell'elenco precedente).
I rettangoli isolati non sono errori (domanda doppia), né i doppi archi tra due nodi (vuol dire essenzialmente che l'intestatario ha presentato due domande).
Per scrupolo (leggasi: per evitare legnate), ho ritenuto opportuno sostituire i codici fiscali con una stringa semicasuale univoca.

Nel caso non abbiate un browser in grado di visualizzare SVG eccovi una versione ridottissima dell'immagine (cliccate per ingrandire):

"Buona" visione!

This fairly long post requires a detailed knowledge of HFS+ internals.
If you don't know what I am talking about, just skip it.

Apple's HFS+ has mostly been stable throughout its life, with few major changes (journaling, HFSX, extended metadata, named forks). It is also very well documented, unlike some other proprietary filesystems I won't name.
With OSX 10.5, Apple introduced Time Machine and threw in the mix two new undocumented HFS+ objects: hard link chains and directory hard links.

The first are a natural extension of the so-called hard link indirect inodes, they just have a new bit (0×020) set in the catalog entry flags to signal that the indirect inode is part of a double-linked list whose elements are all indirect inodes pointing to the same file. This has other ramification into link management and namei resolution which I won't discuss here – if you're curious I suggest you read the source code of XNU's hfs driver here (unless you want to port this feature to other OSes without incurring in Apple's wrath).
The file hard linking mechanism is exactly like the one from 10.3 (eg. old inode is moved into the filesystem's private metadata directory and named iNode%u, etc.). Owner ID and group ID fields are used as list pointers (previous and next element, respectively).

Directory hard linking, instead, is a whole new and inherently dangerous beast: they can be created only under specific circumstances and should not be created or modified by anything other than Time Machine and fsck.hfs.
The VFS on 10.5 sees these links as plain directories, and pre-10.5 systems see them as directory aliases. No other OS with HFS+ support is able to resolve them.

Let's take a closer look.
Directory hard links are in fact indirect hard link inodes: unlike file hard links, they must be part of an hard link chain, have different finder type and creator codes ('fdrp' and 'MACS' respectively), and have a resource fork which allows pre-10.5 systems to access the real directory.
The real directory itself is moved into a special top-level directory called ".HFS+ Private Directory Data\xd" and renamed dir_%u (where %u is its catalog id – inode number in UNIX parlance). It also gets a special extended attribute (com.apple.system.hfs.firstlink) pointing to the head of the link chain.
Like file hard links, the target inode number is stored in place of the link count field and the creation date is set to the filesystem creation date.

The resolution process is fairly straightforward, but that will be fodder for another entry :-)

http://www.patentstorm.us/patents/5764976/fulltext.html

Here's a small excerpt from the ChangeLog:

• Support for hardware virtualization (VT-x and AMD-V) on Mac OS X hosts
• Support for 64-bit guests on 32-bit host operating systems (experimental)
• Experimental 3D acceleration via OpenGL
• Full VMDK/VHD support including snapshots
• New Host Interface Networking implementations for Windows and Linux hosts with easier setup (replaces TUN/TAP on Linux and manual bridging on Windows)

Get it. Now.

Ovvero come perdere mezz'ora abbondante per vedere come interagiscono dei thread/processi (entità schedulabili, va) di un esercizio di Sistemi Operativi.
Molti probe (praticamente tutti tranne i primi due) sono definiti nel programma per evitare di dover usare fbt e/o pid e di dover tirar dentro i dati tramite copyin().

Se non capisci un cazzo di DTrace ti consiglio di leggere qui.

#!/usr/bin/dtrace -s

/* Problema dei baristi - semaphore monitor
 * vim:ts=4:et:
 */

#pragma D option quiet

uint64_t main_ts;

/* Establish time baseline */
pid$target:a.out:main:entry
{
    self->pr_id = pid;
    main_ts = timestamp;
    printf("0 -3 start\n");
}

proc:::exit
/self->pr_id && pid == self->pr_id/
{
    ts = timestamp - main_ts;
    printf("%u -3 end\n", ts);
}

/* Probes for consumer threads */
cliente$target:::start
{
    ts = timestamp - main_ts;
    self->traceme = 1;
    self->cid = arg0;
    printf("%u %d start\n", ts, self->cid);
}

cliente$target:::leave
{
    ts = timestamp - main_ts;
    printf("%u %d leave\n", ts, self->cid);
    self->traceme = 0;
}

/* Probe for producer threads */
barista$target:::start
{
    ts = timestamp - main_ts;
    self->traceme = 1;
    self->cid = (int) arg0;
    printf("%u %d start\n", ts, self->cid);
}

/* Probes for semaphore wait - before semop() call */
sem$target:::wait_enter
/self->traceme/
{
    ts = timestamp - main_ts;
    printf("%u %d wait %d\n", ts, self->cid, arg0);
}

/* after semop() call (non-blocking call or wakeup) */
sem$target:::wait_leave
/self->traceme/
{
    ts = timestamp - main_ts;
    printf("%u %d eow %d\n", ts, self->cid, arg0);
}

/* Record sem_signal calls as well */
sem$target:::signal
/self->traceme/
{
    ts = timestamp - main_ts;
    printf("%u %d signal %d\n", ts, self->cid, arg0);
}

Se qualcuno vi dice di avere le prove che gli ufo esistono, forse dovrebbe vedere questo video…

Da oggi il blog è visibile anche per gli utonti utenti con IPv6.
L'hostname resta lo stesso, magari se non risolvete l'indirizzo IPv6 aspettate 48 ore o flushate la vostra cache DNS :)

Sto migrando il blog su un altro server.
Se vedete i commenti disabilitati vuol dire che la vostra cache dns ha ancora memorizzato il vecchio ip.

A presto su questi schermi :)