Ricordo ancora che tu fosti il primo, poi ci dicemmo che ti saresti sentito solo senza il compagno con cui eri stato insieme per tanto tempo nella gabbia del negozio di animali, e anche Macchia fu dei nostri.

Eravate talmente piccoli che potevo tenervi entrambi sul palmo di una mano.

Poi siete cresciuti e, maschi tutti e due, avete iniziato a azzuffarvi, prede inevitabili degli ormoni. Siamo stati costretti a tenervi separati, ma da allora in poi vi siete sempre comportati da “buoni vicini”.

Sei sempre stato il piu’ curioso dei due, tu, sempre ritto sulle zampe posteriori ad annusare l’aria per capire cosa facessimo noi bipedi, sempre con il collo teso alla ricerca di coccole e prelibatezze.

Sei sempre stato il piu’ debole dei due: piu’ piccolo, con problemi di digestione fin dall’inizio. Ed e’ per probabile colpa del tuo delicato tratto intestinale che te ne sei andato una notte, senza che noi stupidi umani ci fossimo resi conto che stavi male.

Ciao piccolo Nuvola, grazie per essere stato con noi in questi quasi tre anni.

Quindi, in un certo qual senso, sono tornato diciottenne, anche se con molti capelli in meno, oltretutto colorati di bianco, ed un posto da professore per un anno in una universita’ coreana.

Adesso, però, un buon motivo per scrivere ce l’ho. E’ l’ora della verità.

Quale verità, chiedete? Ma è semplice, è il momento di scoprire se l’Italia è una democrazia o meno, e se la legge è uguale per tutti. Ed è il momento di scoprire quanto stupidi, o ipocriti, sono gli italiani.

Il buttasù collettivo

A quando le dimissioni di Nicole Minetti?

Il regno delle chiamate: Rubbi Troia

Nicole Minetti, adesso dimettiti!

“Ho ridato prestigio ed autorevolezza all’Italia in sede internazionale”

Le notizie arrivano fino qui in Corea…

 Teenager: Berlusconi gave me 7000 Euros  

Prosecutors; Berlusconi had many prostitutes

Potete seguire il feed RSS all’indirizzo qui sotto.
http://nexus.thenexus.it/wordpress/podcast/feed/

In alternativa potete fare riferimento al sito di blip.tv, al seguente indirizzo.
http://intothenexus.blip.tv

Senza parole.

Facendo una citazione forse inappropriata: “ed ora, per qualcosa di completamente diverso…”

Ecco a voi la prima intervista di “Into the NeXuS”. Ospite odierno mr. Valentino Berto, bassista eccezionale dei “Silenzio è sexy” e “Le cellule dormienti”, nonchè amico di lungo corso del sottoscritto.
Insieme a Valentino scopriremo i “Silenzio è Sexy”, ripercorreremo la sua carriera artistica e faremo quattro chiacchiere davanti ad una birra virtuale sulla distribuzione commerciale della musica al giorno d’oggi.

Con questa puntata introduco anche una nuova forma di scaletta, spero più chiara della precedente: gli argomenti trattati sono marcati da punti, mentre i brani musicali sono numerati progressivamente.

• Intro

1. Rein – Il deserto di Piero

• Intervista – Parte Prima

2. Silenzio ̬ sexy РCi vuole pazienza

• Intervista – Parte Seconda

3. Silenzio ̬ sexy РNostalgia goodbye

Audio only: Download MP3

Into The NeXuS – 02×01 – Live!

Scarica il file video in formato Flash.

Scarica l’MP3 della trasmissione.

NOTA: L’audio del video (lo so, che giro di parole) e’ ancora quello orginale, molto basso. A presto un nuovo video con audio rimsterizzato (come fa fico!).

Io sto con Emergency.

Ho incominciato a scrivere questo artiocolo (il titolo, per l’esattezza) il giorno del mio compleanno, il 7 Aprile. Oggi e’ il 15 e sto scrivendo le prime parole. Il post sara’ comunque datato al 7, potenza della tecnologia.

Ebbene si’, e’ l’anno 2010 e come tutti i nati nel 1980 (che anno!) oggi compio 30 anni. 30 anni e non sentirli, a volte, o sentirli troppo tal’altre. 30 anni che sono passati in fretta, troppo in fretta, tanto in fretta che faccio fatica a ricordare i momenti migliori. E’ buffo come la mente umana si fossilizzi, tranne in rari fortunatissimi casi, sui ricordi piu’ brutti, su quelle cose che lasciano i segni piu’ profondi, solo per poi arrivare alla fine della via e domandarsi: “Ma chi me l’ha fatto fare di rovinarmi la vita da solo?”.

Dato che anche io faccio parte della schiera dei non-fortunati, e che per tradizione genetica-familiare son tendente alla depressione, mi costa uno sforzo infinito guardare avanti invece che indietro, concentrarmi su cio’ che di bello ho, invece su ciò che di (più) bello vorrei avere.

Eppure questi trent’anni sono stati segnati da un evento felice: sono infatti uomo accasato da 20 Febbraio di quest’anno. E’ stata una scelta ragionata, ma, come tutte le grandi scelte della vita, non senza qualche dubbio, che tutt’ora permane. Tutto stara’ alla mia capacita’ di pensare in positivo e guardare avanti.

Se poi proprio dovessi dirla tutta avevo pensato di iniziare questo post parlando dei fiori di ciliegio (l’albero, sakura in giapponese, qui si chiama 벚나무 [beotnamu], il bocciolo/fiore 벚꽃 [beotgot]) che ho avuto la fortuna di vedere per la terza volta. Non me ne rendo neanche conto, ma sono già passati tre anni da quando sono approdato in questa buffa terra, quasi per sbaglio, con la sensazione che il Giappone fosse così vicino ed invece…

Ed i fiori di ciliegio, sbocciati da appena una settimana o poco più, sono già caduchi, bellezze di breve vita come le farfalle. Ma sboccerano nuovamente l’anno prossimo e quello seguente ancora, ed io forse avrò modo di conoscere di persona tutte quelli che, come fiori di ciliegio, hanno visitato questo blog e mi hanno scritto per chiedermi qualcosa a proposito della Corea e della mia esperienza in questo paese (di cui noi italiani sappiamo così poco) per poi sparire nel nulla.

Dopo i due lunghi stop forzati, dovuti prima alla rottura di uno dei super-magneti (se non ricordo male) e poi del sistema di raffreddamento (complice un pezzettino di pane lasciato forse cadere da un uccello di passaggio), finalmente LHC è stato in grado di portare i flussi a 3.5 TeV (tera elettron-volt) ciascuno, allinearli, ed osservare numerosi e costanti fenomeni dovuti alle collisioni delle particelle ivi contenute.

Anche questa volta non tutto è andato perfettamente liscio, ma per fortuna si è trattato solo di un piccolo intoppo: circa un’ora di stop e si è ripreso. In un primo momento, infatti, a causa dell’accoppiamento elettro-magnetico che si è venuto a creare tra il sistema di generazione ed immissione dei flussi ed il circuito dell’acceleratore vero e proprio, i flussi non sono riusciti a raggiungere i 3.5 TeV previsti.

Via ByoBlu

Mi sono quindi lasciato tentare da un acquisto su eBay: un Intel SS4200-E con 4 dischi Seagate da 750 GiB per la ragionevolissima cifra di 250$ (usato meno di un anno). Trattasi di un NAS progettato e realizzato su stardard aperti (è di fatto un PC) con un case molto più ingombrante e pesante dei “normali” NAS SOHO, ma che da anche una notevolissima sensazione di solidità.

<

I supporti per dischi, sorprendentemente con apertura 'ad ala'.

Nonostante manchi la comoda funzione di hotswap dei drive (la sostituzione è comunque semplice e totalmente tool-less), il sistema è davvero notevole: scheda madre con socket LGA 775, processore Celeron M 420 a 1.6 GHz (core Yonah a 32-bit), 512 MiB di RAM DDR2-667, scheda di rete Gigabit, 4 porte USB (2 frontali e due posteriori), 2 porte e-sata sul posteriore. Inoltre le prestazioni sono di tutto rilievo, come riportato in diverse recensioni e forum (sul forum di OpenFiler si parla di 60-70 MiB/sec tanto in lettura che in scrittura).

Unici veri problemi di questo sistema sono la piattaforma software fornita e la CPU, andiamo a scoprire perché.

Il software è un soluzione Linux based prodotta da EMC e chiamata Lifeline: pur non essendo affatto male, il sistema operativo risulta molto limitato per l’assenza di servizi ormai standard come la gestione integrata di torrent e diverse tecnologie di distribuzione di file multimediali su rete domestica, senza contare gli altri servizi che ho poc’anzi descritto. Inoltre il DOM (Disk-on-module) da soli 256 MiB non permette grandi spazi di manovra.

Il DOM dell'SS4200E, contenente il software EMC Lifeline.

La CPU non è certo un problema in termini di potenza di calcolo: il vero problema è rappresentato dal fatto che, nonostante sia una CPU pensata per notebook, non dispone della tecnologia di variazione dinamica della frequenza di lavoro (denominata Speedstep da Intel), il che porta l’unità a consumare molta più energia del necessario (e comunque molta di più di soluzioni a 4 dischi basate su integrati con architettura ARM, ad esempio).

Come risolvere i problemi sopra indicati? Per quanto riguarda il sistema operativo ho ordinato un DOM da 2 GiB dalla Cina, all’incirca 25 dollari, sul quale credo installerò una verisone stringata ai minimi termini di Ubuntu server a cui poi aggiungerò il necessario per mettere in piedi i servizi di cui sopra. La CPU, invece, è stata rimpiazzata con un Celeron E1500 (50k KRW), ovvero un derivato della serie Core 2 Duo (Conroe 65nm) e frequenza di 2.2 GHz. Tale CPU porta diversi vantaggi tutti insieme: non solo ha un core in più (che mi sarà molto utile per le VM) ed è un processore a 64-bit, ma supporta anche la tecnologia EIST (Enhanced Intel SpeedStep Technology) cosa che lo rende un processore estremamente efficiente sotto il profilo energetico (dissipa solo 8W a riposo).

Il modding comprende anche un adattatore da IDC-10 a DB9 per poter sfruttare la porta seriale on-board, visto che l’SS4200E è una unità headless. In realtà la macchina è dotata di uno slot PCI-Express 1x, ma lo spazio all’interno del case è ridottissimo e dovrei dotarmi di un PCI-Express extender per poter usare una scheda video all’esterno del case.

Non volendo affidare ad una sola unità i miei dati più importanti, utilizzerò uno dei dischi USB che si libereranno come backup della partizione “seria” dell NAS Intel, in modo da garantirmi un margine di sicurezza maggiore.

Ancora la modifica è un work-in progress perché non ho un cavo null-modem per l’installazione del sistema operativo, ma presto vi farò sapere come è andata a finire.

Ottimo, mi pare ovvio visto che lui non fa una benemerita fava (da intendersi come baccello, son pur sempre toscano io) dalla mattina alla sera e prende un sacco di soldi dalle tasche dei contribuenti ogni mese.

Vediamo allora se riesco a spiegare io, a questo mostro di ignoranza, che cosa vuol dire che l’Italia è una Repubblica fondata sul lavoro.

L’articolo 1 della nostra Costituzione repubblicana mette in evidenza la necessità del fatto che tutti lavorino, perché senza il lavoro dei cittadini non è possibile mantenere lo stato sociale. I cittadini, lavorando, creano ricchezza e mettono il paese in grado di competere sul piano dell’import-export. Inoltre, sempre lavorando, i cittadini guadagnano una certa quantità di denaro ogni mese sulla quale devono pagare le tasse (in prima persona o per interposta persona), tasse che confluiscono nelle casse di questa grande macchina che viene chiamata “Stato” e che garantisce (o dovrebbe garantire) servizi di prima e secondaria necessità quali: acqua, elettricità, sanità, trasporti, giustizia, “welfare”, stipendi di parlamentari e senatori, etc. Tali servizi sono forniti a tutti, in egual misura (eccettuati gli stipendi, si intende), e tutti sono liberi di usufruirne proprio perché vige il principio che tutti lavorano e partecipano al benessere del paese, inteso nel senso lato di comunità dei cittadini.

Quindi, caro minestra Brunetta (ché di ministro abbiamo proprio poco, titolo a parte), ecco spiegato il significato dell’articolo primo della Costituzione, in parole credo comprensibili anche ad uno come lei. E non è che ci voglia una laurea per arrivarci (anche se io sto prendendo un dottorato all’estero).

Ho seguito con relativa noncuranza lo sviluppo del linguaggio Go per un po’
di tempo, quando improvisamente mi sono imbattuto in questo post di “Appunti
Digitali” che fa riferimento a questo post su Dalke Scientific.

Mi ha davvero colpito come Stackless Python le dia di santa ragione a Go,
quindi ho deciso di esguire da solo i test sul mio caro vecchio IBM X-41
(Pentium-M 1.5 GHz).

Ho compilato Stackless Python e la toolchain per Go, quindi ho eseguito i
test esattamente come trovati sulla pagina di Dalke. I risultati sono qui
riportati:

$ time ./8.out
100000

real 0m5.197s
user 0m1.508s
sys 0m1.352s

$ time
/usr/local/bin/python2.6 test.py
100000

real 0m3.315s
user 0m1.556s
sys 0m0.148s

Quello che mi ha davvero colpito e’ il fatto che ambo i programmi spendano
aprrossimativamente lo stesso lasso di tempo in userland. Quello che davvero
uccide le prestazioni del programma GO e’ che spende quasi altrettanto tempo in
kernel mode. Mi sono domandato perche’…

Poi mi sono ricordato che, nel Google Tech Talk, Pike dice qualcosa riguardo
al fatto che la runtime di Go gestisce i thread per conto degli utenti, ed io
ho automaticamente interpretato che avrebbe associato i thread utente con gli
OS thread in qualche modo (come e’ la norma). Di fatto questo e’ quello che fa
gccgo (usando gli NTPL).

D’altra partle, leggendo la documentazione di Stackless Python, ho trovato
la pagina riguardante le Tasklets. Si dice chiaramente:
“Le Tasklet sono caratterizzate dall’essere estremamente leggere e portabili, e
sono una eccezionale alternativa a thread di sistema o processi”.

Sono quindi propenso a pensare che le Tasklet siano gestite dalla VM Python
stessa e che non richiedano alcuna transizione user-to-kernel, ne’ altre
interazioni con il kernel… perche’ non sono thread veri (al contrario delle
goroutines in Go).

Questo, con il fatto che Go e’ principalmente inteso per tagliare i tempi
di compilazione, mi fa pensare che la comparativa sia piuttosto ingiusta
e credo che Go garantisca una notevole performance!

Riguardo certe situazioni potenzialmente pericolose ammetto che sono senza
ombra di dubbio un problema. In ogni caso credo che verranno trattate molto in
fretta: Go e’ un linguaggio appena sfornato e qualche spigolatura qua e la non
puo’ essere che attesa, pur con un grande spazio di crescita.

Update:

Ho modificato i programmi di test cosi’ che ogni goroutine/Tasklet chiami una
seconda funzione che cicla 1000 volte e cumula il risultato di “sum = sum+1″.

I risultati sono come previsto: il compilato e’ un ordine di grandezza piu’
veloce dell’interpretato Stackless Pyhton! Ho anche rimpiazzato la chiamata a
range con xrange, come suggerito da Cesare
Di Mauro, ma non ha cambiato molto le cose… cosi’ come non le ha cambiate
usare psyco (un JIT per Python).


$time ./test2 && time /usr/local/bin/python test2.py
100000

real 0m19.567s
user 0m15.697s
sys 0m0.160s


The source code for Python is:
default=100000)

stackless.tasklet(main)()
stackless.run()


And the test code for Go is:
"fmt";
)

func main() {
flag.Parse();
leftmost := make(chan int);
var left, right chan int = nil, leftmost;
for i := 0; i < *ngoroutine; i++ {
left, right = right, make(chan int);
go f(left, right);
}
right <- 0; // bang!
x := <-leftmost; // wait for completion
fmt.Println(x); // 100000
}


Piu’ precisamente si tratta del M-Audio Audio Buddy (mic preamp) e del Blue Microphones Icicle .

L’Audio Buddy e’ stato acquistato perche’, avendo io un microfono a condensatori ed uno dinamico, se volessi usarli insieme mi sarebbe molto comodo per equalizzare i livelli di ingresso, nonche’ per aumentare un po’ il guadagno (un po’ bassino anche con il Behringer C-1 che sto usando attualmente).

L’Icicle, invece, e’ stato acquistato in previsione dell’arrivo dell’OpenPandora: trattandosi di una periferica USB standard dovrebbe essere perfettamente supportata anche da Linux… ed OpenPandora, nonostante abbia gia’ un microfono interno ed un jack di ingresso da 3.5 mm, ha anche una porta USB 2.0 Host che passa tutti i 500 mA necessari ad alimentare periferiche esterne. Qui c’e’ una review di Gear Diary che indica come la periferica funzioni correttamente con Ubuntu 9.10, al contrario che con la 9.04. Vedremo con Ängstrom Linux!

Quindi via al podcasting on the road di qualita’!

EDIT: Mi sono ovviamente sbagliato con la numerazione e questo e’ l’episodio 8! Grazie Rouge!