Fra le applicazioni che ho segnalato qualche tempo fa c’era MacFusion, ovvero un’interfaccia grafica per configurare e usare MacFuse, uno filesystem “user-level”.

Quest’applicazione mi interes­sava come supporto alle procedure di installazione, per limitare al mas­simo l’interazione via shell remota. Volevo capire se era una cosa fattibile e se ne valeva la pena, anche tenendo conto delle limitazioni segnalate nelle FAQ.

Per l’uso di MacFusion sono richiesti Mac OS X 10.5 e MacFuse. Avrei voluto installare quest’ultimo tramite MacPorts ma purtroppo è una versione troppo vecchia (1.7 contro l’attuale, 2.0.x); si tratta comunque di un’operazione velocis­sima, che non richiede nemmeno il riavvio, per cui anche l’installazione manuale è alla portata di chiunque. Il pacchetto comprende, oltre all’estensione del kernel e alle varie librerie, un comodo pannello di controllo:

MacFusion invece consiste solo nell’applicazione e, se lo desideriamo, dell’eventuale icona nella barra dei menu.

A questo punto pos­siamo definire i volumi remoti. L’operazione è molto semplice e riporto quindi solo gli screenshot per la configurazione dell’SSHFS, che credo si commentino da soli:

Fin qui abbiamo parlato dell’uso più standard, quello che copre il 90% dei casi. Ma per essere utile nelle installazioni bisogna verificare se è  pos­sibile l’uso da linea di comando.

La versione distribuita sul dmg non contiene nes­suno strumento per il terminale ma è scaricabile dalla repository svn. Il link riporta anche le istruzioni per il suo uso, molto semplice; altrettanto semplice diventa la sua integrazione nelle operazioni di deployment.

A questo punto abbiamo tutti i pezzi neces­sari e funzionanti. Vale la pena di usarli nel deployment? A mio parere, dipende dall’approccio alla sicurezza che viene usato sul server di destinazione: se facciamo tutto come root, a partire dall’ssh iniziale, allora non cambia praticamente nulla; se entriamo come utente “normale” e poi usiamo sudo, va ancora peggio, perché l’uso di sudo è ovviamente escluso a priori; infine, se abbiamo impostato i privilegi — magari tramite acl — in modo tale che l’utente dell’ssh possa anche portare a termine l’installazione senza sudo allora pos­siamo trarne qualche beneficio.

In quest’ultimo caso, il vantaggio principale consiste nell’avere a disposizione l’intero “arsenale” della propria macchina locale per operare sul volume  del server remoto. Viceversa, il difetto principale è che l’uso dell’SSHFS può non essere una soluzione completa: se l’installazione pre­vede il riavvio di un qualche processo dovremo comunque usare l’ssh.

Tuttavia, anche se non ne ho fatto l’uso esteso che pensavo, mi sono trovato più di una volta nella neces­sità di usare MacFusion per verifiche o interventi “al volo” e rimane uno strumento di grande utilità.

Delle caratteristiche di iPhoto 09 quella che mi sembra più interes­sante (per un non fotografo come me, voglio dire) è quella del riconoscimento facciale. Non tanto per la tecnologia in sé, che non credo sia una novità assoluta, quanto perché lascia sperare un’estensione futura a livello di sistema operativo di questa feature.

Il primo utilizzo ovvio potrebbe essere quello dell’autenticazione ma poi si pos­sono immaginare altri scenari più o meno futuribili, ad esempio con iChat dove l’immagine dell’interlocutore è piuttosto fissa e non dovrebbe essere difficile estendere l’uso anche a quello scenario. Si vedrà…

Rispetto ai tempi del Mac OS “clas­sico” le parti sembrano essersi invertite: allora, le tecnologie erano sempre introdotte a livello del sistema operativo, in attesa — spesso frustrata — delle applicazioni che le avrebbero poi sfruttate; ora sono spesso le applicazioni di Apple a fare da apripista o comunque a trainare e indirizzare l’evoluzione del sistema operativo.

Come sono lontani i tempi di “My voice is my pas­sword”.

È uscita la beta di LaunchBar 5!

Sono un assiduo utilizzatore di LaunchBar # e anche se curiosamente non controllo mai eventuali aggiornamenti, appena vengo a conoscenza di qualche novità corro subito ad installare l’ultima versione.

Le novità più rilevanti sono:

1. cronologia archivio appunti;
2. supporto per Quick Look;
3. le azioni;
4. la calcolatrice.

Cronologia archivio appunti

Una delle mancanze più sentite in Mac OS X è la mancanza di un equivalente del kill ring di Emacs, in modo da poter conservare più oggetti copiati per un uso futuro. Nell’ultima versione di LaunchBar è pos­sibile usare la “Clipboard History”; è attiva di default e funziona in modo trasparente, memorizzando ogni operazione di copia (fino a un mas­simo di quaranta).

Il contenuto è disponibile con tre combinazioni da tastiera ma, in linea con la filosofia di fondo LaunchBar cerca di eliminare il più pos­sibile dei pas­saggi inutili. Non solo è pos­sibile richiamare la storia dell’archivio appunti per poi selezionare, dando invio, l’elemento voluto, ma pos­siamo anche sceglierlo direttamente al rilascio del tasto, definibile, di selezione.

Supporto per Quick Look

Adesso è pos­sibile visualizzare l’anteprima dei documenti direttamente da LaunchBar, con le stesse abbreviazioni che si usano nel Finder. 

Le azioni

L’architettura è stata rivista e ne sono state aggiunte molte altre. Adesso è sufficiente mettere le proprie azioni in ~/Library/Application Support/LaunchBar/Actions perché vengano rilevate dall”applicazione. 

Inoltre vengono indicizzati anche i servizi. Vediamo se comincerò ad utilizzarli di più.

Credo che in quest’area QuickSilver rimanga comunque superiore, perché è più chiara la concatenazione delle azioni. 

La calcolatrice

Con questa release, è difficile trovare un motivo per usare una delle varie calcolatrici disponibili come widget. Adesso sono disponibili le funzioni scientifiche più comuni, con tanto di abbreviazioni (ad es. sin(33) può essere scritto come S33), ed è anche pos­sibile estendere le funzionalità con delle macro.

Ispirato da questo post di Tim Bray, ecco qualche nota su come uso attualmente Mac OS X e le varie applicazioni, in particolare per i punti in cui trovo differenze interessanti.

Setup generale

La mia macchina di lavoro attuale è un MacBook ma uso ancora un iMac della penultima generazione per varie cosette, tutte piuttosto frivole. Per rendere l’idea, le applicazioni che uso di più sul MacBook sono Emacs (da MacPorts) e la shell; sull’iMac è NetNewsWire.

Anche se è un’abitudine che è nata un po’ per caso e un po’ neces­sità, ho finito per trovare molto comoda la divisione dei compiti fra la due macchine. Il MacBook significa più o meno lavoro, l’iMac significa più o meno ricreazione. Questa divisione mi ha anche aiutato a dare un taglio netto alle vecchie abitudini di cominciare la giornata con il cappuccino e la brioche dell’internauta: email e web. Sbrigo la posta di lavoro in due o tre momenti chiave della giornata e lascio alle fasi serali le mailing list e i feed RSS.

La condivisione dei dati

Il dilemma dell’avere una o più macchine è sempre legato ai dati e al loro accesso. Tim Bray nel suo post sottolinea i vantaggi della macchina unica e non ha torto. Nel mio caso, vista la ripartizione degli usi, la questione è meno sentita. In ogni caso, la sincronia fra la due macchine non è un problema: tutti i progetti importanti sono in Subversion; il bricolage sta tutto su MobileMe; i bookmarks sono su Delicious.

Entro la fine dell’anno porterò tutti gli articoli ancora rilevanti in Evernote e tutti gli altri documenti su MobileMe. Vorrei anche spostare la libreria di iTunes su un server in LAN, un Mac Pro che ospita anche la repo di Subversion, i backup di Time Machine, database, ecc ecc.

Una cosa che non ho e che invece è di fondamentale è un monitor esterno. Il vantaggio di produttività è innegabile, senza calcolare la posizione di lavoro ecc.

Organizzazione dei documenti

Questo è la parte del post di Tim Bray che mi ha dato il vero stimolo per scrivere questo post. Quando ho letto che organizza i file per data sono rimasto un po’ perplesso. Premetto che sicuramente avrà un sacco di file in più dei miei quattro ma ho la sensazione che il mio sistema potrebbe funzionare anche nel suo caso.

Qual è il mio “sistema”? È praticamente inesistente: tranne che per qualche file particolarmente usato butto tutto nella cartella dei documenti e lo cerco con spotlight. Fine della storia. Lo stesso vale per la posta elettronica, dove ho una sola cartella di archiviazione, per la posta di lavoro. Le mailing list hanno le loro cartelle e vengono svuotate periodicamente da uno script in perl che le passa in ras­segna, eliminando i mes­saggi più vecchi di 15 giorni.

Il dock. Cos’è il dock?

Anche questo mi ha fatto sorridere. Anch’io, come Tim Bray, tenevo il dock sulla destra, sempre visibile. Adesso l’ho riportato sotto ed è nascosto. Tuttavia, non ho nes­suna icona fissa nel dock, tranne quella di LaunchBar, che per me rimane la utility.

A onor del vero, con Leopard il Dock mi risulta un po’ più utile per via della gestione delle cartelle ma rimane una cosa a cui potrei rinunciare. Al pari di altre idee, come Spaces, il Dock è stato tanto una folgorazione alla prima demo e un non-evento nell’uso concreto. Non è cha sia stato deluso al contatto diretto: sia il Dock che Spaces fanno quanto promesso ma semplicemente non li ho trovati utili.

Il terminale

Uso screen e dopo anni di culto delle tinte scure con un tocco di trasparenza sono pas­sato allo sfondo bianco con testo nero/grigio. Allo stesso modo, dopo anni di Monaco 10, sono pas­sato a… niente. Sono indeciso fra il Courier ed Envy Code R ma non ne ho ancora trovato uno che mi soddisfi fino in fondo.

Direi che mi sono dilungato fin troppo… E pensare che non ho preso in considerazione l’iPhone!

Noto con piacere (e con un po’ di invidia) che Laburno si è comprato il nuovo MacBook e che ne sembra molto soddisfatto; ed è anche diventato un utilizzatore di Coda.

Ragion per cui segnalo questo trucchetto, proprio per Coda, per aggiungere nuove reference a quelle già esistenti.

Avendo migrato qualche giorno fa i miei progetti in Trac da FreeBSD a Mac OS X, avevo deciso di usare l’open directory per l’autenticazione, così, tanto per gradire. Tutto bene.

Oggi, improvvisamente, gli utenti non riescono più ad autenticarsi. Per motivi ancora tutti da accertare Kerberos ha smesso i funzionare. Panico: la cura standard per problemi del genere è la reinstallazione.

Poi mi sono ricordato che ho eseguo dei backup giornalieri di tutta l’Open Directory. Il tempo di indicare il disco immagine, inserire la pas­sword e tutto è tornato come prima.

La parte mezza vuota del bicchiere è che Open Directory non dovrebbe essere così delicata, la parte mezza piena è un sabato mattina dedicato a cose più produttive ;-)

Per ragioni storiche (con la “s” molto minuscola) molti utenti che attualmente usano Mac OS X hanno una conoscenza relativa dell’uso della shell e anche i più bravi hanno comunque bisogno di un aiutino.

Nel tempo ho provato diverse soluzioni per tenere segnati i comandi che, essendo magari usati solo raramente, devono ogni volta essere “riscoperti”, ma senza particolare successo. Quello che succede più frequentemente è che non mi ricordo nemmeno di guardare (idem con i vari alias).

Adesso ho scoperto Clix e sono curioso di vedere se può migliorare qualcosa. L’applicazione è molto semplice: dopo aver creato un nuovo file in cui salvare i comandi, ne aggiungiamo uno con ALT-CMD-RET e compiliamo le informazioni necessarie:

Form per l’aggiunta di un comando

 Fatto questo pos­siamo lanciare il comando ed eventualmente copiarne il risultato:

Esecuzione del comando

Non male, vero?

Non so bene come valutare l’ultimo periodo per Apple. Da una parte gli affari vanno bene (1, 2) ma dall’altra sono stati combinati diversi casini: la transizione a MobileMe; la qualità di MobileMe stesso; la questione della salute di Jobs; infine, l’attesissima patch contro l’inquinamento della cache (cache poisoning) del DNS.

Non conosco i dettagli specifici di questa versione ma, parlando in termini generali, il cache poisoning consiste nel fare in modo che, quando interroghiamo il DNS per chiedere a quale indirizzo IP corrisponde un certo nome di dominio, come ad es. refactor.it, non otteniamo in risposta l’indirizzo corretto ma un altro, consentendo in questo modo all’autore del cache poisoning di indirizzare gli ignari utenti su siti che nulla hanno a che fare con quelli veri: voi pensate di accedere al vostro conto in banca e in realtà dall’altra parte c’è già qualcuno che si frega le mani (sì, lo so che state pensando che non è poi così diverso dal banchiere ma è per rendere l’idea).

Ora, come spesso succede, questa vulnerabilità è stata scoperta molto tempo fa (circa sei mesi) e il responsabile, Dan Kaminsky, ha tenuto segreta la cosa dando così il tempo di trovare il rimedio. Come altrettanto spesso succede, la notizia è trapelata ed è scattata la corsa fra i cercatori del rimedio e i cercatori del raggiro. (3)

In tutta questa trafelata corsa nel rimettere insieme i cocci, chi è rimasto clamorosamente indietro è stata Apple, che solo ieri ha rilasciato la patch e solo per Mac OS X Server. È probabile che la causa di questa lentezza sia legata al processo di controllo qualità a cui sono sottoposti gli aggiornamenti software ma ciò non toglie che Apple non è stata in grado di reagire in modo tempestivo e questo va corretto, altrimenti il mercato enterprise rimarrà sempre in mano ad altri e per buoni motivi.

Altri link:

• “DNS Clients Have Small Vector of Risk after Patch”: un bel post sulle probabili cause del ritardo, sulla sua gravità e sui pos­sibili rimedi da uno che in Apple ci ha lavorato;
• “Opinion: Apple’s unforgivable DNS delay”: critica severa ma giusta su tutto l’affaire;
• “The DNS Vulnerability”: cito di nuovo questo articolo perché nella seconda parte offre spunti anche per una critica più radicale a tutta le questione della sicurezza.

Dopo un’attesa biblica per la disponibilità del servizio, finalmente sono riuscito a dare un’occhiata a Mobile Me. Sapevo più o meno cosa attendermi e sapevo anche tutta la storia del push era comunque una cosa apprezzabile solo dai fortunati pos­ses­sori di un iPhone.

Quindi ho solo cercato di rispondere alla domanda: a quali applicazioni posso rinunciare per la versione on–line?

Mail

A livello funzionale non mancherebbe molto ma il problema rimangono le regole per smistare i mes­saggi. Tutte le mailing list a cui sono iscritto vengono smistate in cartelle in IMAP e quindi, in linea teorica, potrebbe essere spostate sul server ma questa pos­sibilità non esiste. Rimango con la versione desktop.

iCal

Qui l’illusione del desktop è ancora più perfetta ma il funzionamento è erratico. Sul mio portatile, che usa ancora Tiger, funziona bene; sull’iMac non c’è verso e non ne vedo proprio il motivo. Che senso usare usare un’applicazione via web se poi funziona solo con un computer? E con lo stesso browser!

I problemi più grossi, tuttavia, sono con la sottoscrizione di altri calendari: semplicemente, non si può e in ogni caso pare non vengano pas­sati verso l’iPhone. Non ci siamo.

Address Book

Questa è l’unica applicazione che non fa rimpiangere la versione desktop, soprattutto da quando, con Leopard, non è più pos­sibile inviare sms via bluetooth. Ci sono dei bugs qua e là ma, insomma, ci siamo.

In conclusione

Mail: desktop, iCal: desktop, Address Book: web. Senza le limitazioni incomprensibili su iCal qualche pensiero in più l’avrei fatto. Per l’email la questione è un po’ più complessa. È vero che le regole non sono fantascienza ma sono usate di quanto si pensi e credo che Apple avesse in testa quel tipo di utenti, come profilo ideale. 

Vedremo i pros­simi passi.