È il pesce combattente del Siam, un
bellissimo pesce tropicale, ma con una caratteristica interessante: è
estremamente aggressivo. La credenza popolare vuole che due maschi si combattano
anche in natura, ma non è proprio vero. Questa credenza deriva dal comportamento
del pesce in acquario, dove il vincitore attacca continuamente il perdente,
causandone alla fine la morte.
Ora, pensate all’ecosistema software come a un acquario. E pensate a Microsoft
dentro questo acquario. L’ultima release del sistema operativo Microsoft ha un
pesce aggressivo come skin predefinita, ed è solo in questo acquario. E non c’è
posto per nessun altro: combatteranno qualsiasi avversario, anche se della
stessa specie.
Quel che è incerto è… ci riusciranno, o no? :). Staremo a vedere!
La sessione a destra mostra un documento aperto su un dispositivo audio aggregato tra soundflower (2 canali) e una Creative SBLive con 6 canali: il flower riceve l’input audio da iTunes e lo indirizza ai canali della scheda, usando tutti e 6 gli speaker.
Sono stati aggiunti degli effetti per migliorare l’esperienza audio (dettagli qui: http://www.rottenbrains.com/?p=232). La sessione a destra usa anche AUNetSend per streamare l’audio verso la sessione a sinistra, connessa agli speaker integrati del MacBook.
Risultato: audio stereo riprodotto su otto canali. Le Audio Units sono uno strumento davvero potente, ben scritto e ben funzionante.
[grazie a nextie per avermi detto di AUNetSend e AUNetReceive]
AGGIORNAMENTO 19-12-2008
Miglioramento: non c’è bisogno di usare NetSend e NetReceive per riprodurre su 8 speaker: un dispositivo aggregato composto da Soundflower 2ch, la SBLive USB a 6 canali e l’uscita Built-in è sufficiente!
Inoltre, nota il nuovo bus: è necessario perché l’effetto AUMatrixReverb aggiunto al canale centrale per migliorare la stereofonia dell’audio in realtà occupa due canali, e quindi si sovrappone a quello successivo (il LFE). Ma applicare l’effetto a un bus non presenta questo effetto collaterale.
Quando raggiungeremo il punto in cui l’anonimato online sarà finito, invece
di poter essere chi siamo davvero, il fatto di essere diventati così
consapevoli di essere sempre registrati, fotografati, tracciati e seguiti,
avrà in realtà creato una personalità leggermente alterata. Come i
concorrenti dei reality TV, l’atto di essere osservati cambierà il nostro
comportamento. L’immagine del nostro brand personale diventerà la nostra
identità pubblica e quindi la nostra identità.
Direi che queste parole descrivono perfettamente l’“effetto Facebook”.
Se ti stai chiedendo perché il demone CCacheServer, che tiene in memoria
i ticket Kerberos ottenuti tramite kinit(1), NON parte… è a causa di un
bug strano riguardante il LimitLoadToSessionType specificato nel .plist
dell’agent, che si trova in
/System/Library/LaunchAgents/edu.mit.kerberos.CCacheServer.plist sui sistemi
OSX 10.5.
CCacheServer verrà poi istanziato quando fai un kinit:
$ kinit
Please enter the password for vjt@DOMAIN.LOCAL:
$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: vjt@DOMAIN.LOCAL
Valid Starting Expires Service Principal
11/12/08 20:59:35 11/13/08 06:59:14 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 11/19/08 20:59:35
Il bug è strano perché la chiave LimitLoadToSessionType dovrebbe in realtà
istruire launchd ad avviare automaticamente il demone e farlo girare una volta
per ogni utente
loggato,
quando kinit ne richiede i servizi. Ma se la chiave è impostata nel .plist,
un launchctl load su di esso fallisce con “nothing found to load”. Assurdo!
Se usi l’integrazione con Lighthouse fornita da GitHub, dalle pagine “Admin”
del tuo repository git, potresti esserti imbattuto in un difetto: ogni
changeset su Lighthouse appare come se fosse stato fatto dall’utente Lighthouse
che ha configurato l’integrazione su GitHub.
Questo succede perché Lighthouse usa il token API per collegare gli autori dei
changeset agli utenti LH, e non va bene quando non sei l’unico a fare commit :-).
Una soluzione semplice è usare un hook post-commit, come descritto
qui,
ma non è soddisfacente perché significa che ogni volta che esegui git commit
dalla tua console, il messaggio del commit diventa pubblico, e se fai
--amend o reset --soft dell’index dovrai andare su Lighthouse a cancellare
il changeset.
Una soluzione molto più furba è pushare tutte le revisioni modificate quando
le si pusha su GitHub: ho modificato l’hook post-commit
originale e l’ho installato accanto al comando
git in $(dirname which git)/git-lh.
Questo mi dà un nuovo comando git lh che recupera la revisione HEAD corrente
da GitHub usando refs/heads/master e fa POST di ogni changeset tra quella
revisione e il tip corrente nel working tree verso Lighthouse.
Quindi, se esegui git lh prima di git push, ogni modifica che stai
pushando su GitHub andrà anche su Lighthouse.
AGGIORNAMENTO: Un semplice script bash tipo:
#!/bin/bash
git lh && git push
salvato come git-lh-push ti risparmia di digitare due comandi quando vuoi fare push :).
“Quando ti sembra di avere troppe cose da gestire nella vita, quando 24 ore in
un giorno non sono abbastanza, ricordati del vaso della Maionese e dei due
bicchieri di vino…”
Un professore stava davanti alla sua classe di filosofia e aveva davanti alcuni
oggetti.
Quando la classe incominciò a zittirsi, prese un grande barattolo di maionese
vuoto e lo iniziò a riempire di palline da golf. Chiese poi agli studenti se il
barattolo fosse pieno e costoro risposero che lo fosse.
Il professore allora prese un barattolo di ghiaia e la rovesciò nel barattolo
di maionese. Lo scosse leggermente e i sassolini si posizionarono negli spazi
vuoti, tra le palline da golf. Chiese di nuovo agli studenti se il barattolo
fosse pieno e questi concordarono che lo fosse.
Il professore prese allora una scatola di sabbia e la rovesciò, aggiungendola
nel barattolo; ovviamente la sabbia si sparse ovunque all’interno. Chiese
ancora una volta se il barattolo fosse pieno e gli studenti risposero con un
unanime “Si!”.
Il professore estrasse quindi due bicchieri di vino da sotto la cattedra e
aggiunse il loro intero contenuto nel barattolo, andando cosi effettivamente a
riempire gli spazi vuoti nella sabbia. Gli studenti risero.
“Ora”, disse il professore non appena la risata si fu placata, “voglio che
consideriate questo barattolo come la vostra Vita. Le palle da golf sono le
cose importanti: la vostra famiglia, i vostri bambini, la vostra salute, i
vostri amici e le vostre Passioni; le cose per cui, se anche tutto il resto
andasse perduto e solo queste rimanessero, la vostra vita continuerebbe ad
essere piena. I sassolini sono le altre cose che hanno importanza, come il
vostro lavoro, la casa, la macchina… La sabbia è tutto il resto: le piccole
cose.
Un mio amico mi ha detto che sui blog
tecnici gira un nuovo meme: mostrare i comandi più usati, partendo dalla
history della shell:
history | \
awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | \
sort -rn | head -15
Io ho 20 volte la dimensione di default della bash history (10k righe), quindi
i risultati saranno interessanti. Uso anche la funzione di timestamp della
history, quindi ho aggiunto un piccolo sed al codice per eliminare i timestamp.
Vediamo un po':
vjt@voyager:~/code*$* history |
sed 's#^[ 0-9\[\/\:]*\]\([^ ]*\).*#\1#' |
awk '{a[$1]++}END{for(i in a){print a[i] " " i}}' |
sort -rn | head -15
928 l
577 ssh
389 ping
381 cd
300 dig
259 telnet
153 sudo
126 ifconfig
125 whois
113 ps
96 svn
91 cat
73 fg
68 vi
61 ..
Già, faccio un SACCO di ls, l in realtà è ls -alFGs (sono su Darwin). Questa
lista rivela le mie abitudini recenti, perché sto scrivendo meno codice e
gestendo di più (niente gcc, niente irb, un sacco di dig & whois). svn è
ancora lì, ovviamente ;). ssh significa che questi risultati andrebbero
aggregati con le history delle altre macchine su cui mi loggo… ma quello è
argomento per un altro post ;).
Quali sono i tuoi risultati?
Postali qui! :D
AGGIORNAMENTO 2008-06-03
Dato che le mie abitudini recenti sono più di coding che di scrittura di documentazione, ho rieseguito l’analisi della history… e questi sono i nuovi risultati:
1796 l
981 svn
705 ssh
693 cd
666 ping
402 vi
356 ifconfig
352 telnet
321 dig
315 sudo
283 fg
240 grep
188 ..
183 cat
157 ps
AGGIORNAMENTO 2009-02-20
5427 l
4379 git
3128 svn
2812 vi
2105 cd
1408 ping
1392 fg
1328 ssh
935 ifconfig
893 grep
890 sudo
733 rake
653 cat
554 ..
535 ruby
AGGIORNAMENTO 2009-05-24
7374 l
5041 git
3265 vi
3131 svn
2753 cd
1881 ssh
1763 ping
1618 fg
1101 sudo
1100 ifconfig
977 grep
867 cat
767 rake
721 telnet
671 ..
AGGIORNAMENTO 2010-06-01
20517 git
7794 l
1906 cd
1631 rg
1518 vi
1108 rake
1041 cat
1010 ruby
790 sudo
754 fg
676 make
670 script/console
626 rm
496 ping
474 ..
AGGIORNAMENTO 2012-07-23
3367 l
2685 ssh
1289 cd
1013 curl
976 git
857 sudo
815 ping
526 telnet
521 ps
497 cat
472 port
422 fg
400 vi
274 rm
259 dig
