Da qual­che giorno è dispo­ni­bile la beta di Safari 4. Come molti potranno intuire, uno degli ele­menti di discus­sione più fre­quenti, se non il più fre­quente, è il rifa­ci­mento dei tab.

Le cri­ti­che di solito riguar­dano l’usabilità. Avendo ripo­si­zio­nato i tab insieme alla barra del titolo viene a man­care un’area dal com­por­ta­mento pre­ve­di­bile: tolti i pul­santi di zoom, con­tra­zione e chiu­sura sulla sini­stra e quello di con­tra­zione della tool bar sulla destra, il resto della barra era uti­liz­za­bile per il tra­sci­na­mento con il mouse.

In Safari 4, man mano che i tab aumen­tano aumen­tano anche le pro­ba­bi­lità di clic­care sui pul­santi di chiu­sura o sulla zona per “estrarre” il tab e ren­derlo una fine­stra a sé stante. Per non par­lare del pul­sante di aggiunta del tab.

Dall’altro lato, il van­tag­gio più citato è l’uso un po’ più effi­ciente dello spa­zio ver­ti­cale, che lascia una man­ciata di pixel in regalo al contenuto.

Un’altra que­stione non tra­scu­ra­bile è capire se que­sta novità sia l’anteprima di quello che verrà in futuro esteso a tutto il sistema ope­ra­tivo o rimarrà una pecu­lia­rità di Safari.

Breve inciso. Da quando Mac OS X è uscito (sem­bra un secolo, ormai) una delle lamen­tele più fre­quenti è stata quella di una certa per­dita di coe­renza dell’interfaccia fra le varie appli­ca­zioni, a par­tire pro­prio da quelle di Apple. Basta pren­dere Mail, Safari, iTu­nes, iChat, fino ad arri­vare a casi cla­mo­rosi come le appli­ca­zioni pro come Final Cut e Aperture per tro­vare una grande varietà di solu­zioni a pro­blemi comuni. La cri­tica sulla coe­renza è ragio­ne­vole, ma credo che ci sia un altro aspetto da non tra­scu­rare che riguarda la “spe­cia­liz­za­zione” — e di con­se­guenza l’efficienza — dell’interfaccia. Ho l’impressione che Apple abbia allen­tato la rigi­dità sull’omogeneità delle GUI per lasciare più spa­zio a solu­zioni adatte a una cer­chia ristretta di sce­nari; il primo obiet­tivo diven­te­rebbe quindi l’efficienza all’interno dell’applicazione e solo dopo si pone la que­stione dell’aderenza alle linee guide dell’interfaccia. Fine inciso.

Dicevamo dei nuovi tab di Safari. A mio parere, se diamo per buona la diversa meta­fora - non più tab ma fine­stre asso­ciate le une alle altre - sug­ge­rita dalla nuova solu­zione, l’implementazione sia ancora carente. In par­ti­co­lare, il pul­sante di chiu­sura del tab potrebbe con­fluire nel gruppo degli attuali pul­santi sulla sini­stra (non chie­de­temi come).

La lin­guetta nell’angolo a destra pone qual­che pro­blema in più: se venisse spo­stata in una zona comune biso­gne­rebbe allora fare un’operazione in più per por­tare a ter­mine il com­pito dato che il tab dovrebbe prima venire attivato.

In chiu­sura, cam­biando com­ple­ta­mente argo­mento, trovo incom­pren­si­bile la rimo­zione della barra di cari­ca­mento dal campo dell’URL. Sarà per­ché ci sono affe­zio­nato, non so, ma non vedo alcun van­tag­gio nel toglierla; mi sem­bra un mini­ma­li­smo fine a se stesso, non vi pare?

Fra le appli­ca­zioni che ho segna­lato qual­che tempo fa c’era MacFusion, ovvero un’interfaccia gra­fica per con­fi­gu­rare e usare MacFuse, uno file­sy­stem “user-level”.

Quest’applicazione mi inte­res­sava come sup­porto alle pro­ce­dure di instal­la­zione, per limi­tare al mas­simo l’interazione via shell remota. Volevo capire se era una cosa fat­ti­bile e se ne valeva la pena, anche tenendo conto delle limi­ta­zioni segna­late nelle FAQ.

Per l’uso di MacFusion sono richie­sti Mac OS X 10.5 e MacFuse. Avrei voluto instal­lare quest’ultimo tra­mite MacPorts ma pur­troppo è una ver­sione troppo vec­chia (1.7 con­tro l’attuale, 2.0.x); si tratta comun­que di un’operazione velo­cis­sima, che non richiede nem­meno il riav­vio, per cui anche l’installazione manuale è alla por­tata di chiun­que. Il pac­chetto com­prende, oltre all’estensione del ker­nel e alle varie libre­rie, un comodo pan­nello di controllo:

MacFusion invece con­si­ste solo nell’applicazione e, se lo desi­de­riamo, dell’eventuale icona nella barra dei menu.

A que­sto punto pos­siamo defi­nire i volumi remoti. L’operazione è molto sem­plice e riporto quindi solo gli screen­shot per la con­fi­gu­ra­zione dell’SSHFS, che credo si com­men­tino da soli:

Fin qui abbiamo par­lato dell’uso più stan­dard, quello che copre il 90% dei casi. Ma per essere utile nelle instal­la­zioni biso­gna veri­fi­care se è  pos­si­bile l’uso da linea di comando.

La ver­sione distri­buita sul dmg non con­tiene nes­suno stru­mento per il ter­mi­nale ma è sca­ri­ca­bile dalla repo­si­tory svn. Il link riporta anche le istru­zioni per il suo uso, molto sem­plice; altret­tanto sem­plice diventa la sua inte­gra­zione nelle ope­ra­zioni di deployment.

A que­sto punto abbiamo tutti i pezzi neces­sari e fun­zio­nanti. Vale la pena di usarli nel deploy­ment? A mio parere, dipende dall’approccio alla sicu­rezza che viene usato sul ser­ver di desti­na­zione: se fac­ciamo tutto come root, a par­tire dall’ssh ini­ziale, allora non cam­bia pra­ti­ca­mente nulla; se entriamo come utente “nor­male” e poi usiamo sudo, va ancora peg­gio, per­ché l’uso di sudo è ovvia­mente escluso a priori; infine, se abbiamo impo­stato i pri­vi­legi — magari tra­mite acl — in modo tale che l’utente dell’ssh possa anche por­tare a ter­mine l’installazione senza sudo allora pos­siamo trarne qual­che beneficio.

In quest’ultimo caso, il van­tag­gio prin­ci­pale con­si­ste nell’avere a dispo­si­zione l’intero “arse­nale” della pro­pria mac­china locale per ope­rare sul volume  del ser­ver remoto. Viceversa, il difetto prin­ci­pale è che l’uso dell’SSHFS può non essere una solu­zione com­pleta: se l’installazione pre­vede il riav­vio di un qual­che pro­cesso dovremo comun­que usare l’ssh.

Tuttavia, anche se non ne ho fatto l’uso esteso che pen­savo, mi sono tro­vato più di una volta nella neces­sità di usare MacFusion per veri­fi­che o inter­venti “al volo” e rimane uno stru­mento di grande utilità.

Delle carat­te­ri­sti­che di iPhoto 09 quella che mi sem­bra più inte­res­sante (per un non foto­grafo come me, voglio dire) è quella del rico­no­sci­mento fac­ciale. Non tanto per la tec­no­lo­gia in sé, che non credo sia una novità asso­luta, quanto per­ché lascia spe­rare un’estensione futura a livello di sistema ope­ra­tivo di que­sta feature.

Il primo uti­lizzo ovvio potrebbe essere quello dell’autenticazione ma poi si pos­sono imma­gi­nare altri sce­nari più o meno futu­ri­bili, ad esem­pio con iChat dove l’immagine dell’interlocutore è piut­to­sto fissa e non dovrebbe essere dif­fi­cile esten­dere l’uso anche a quello sce­na­rio. Si vedrà…

Rispetto ai tempi del Mac OS “clas­sico” le parti sem­brano essersi inver­tite: allora, le tec­no­lo­gie erano sem­pre intro­dotte a livello del sistema ope­ra­tivo, in attesa — spesso fru­strata — delle appli­ca­zioni che le avreb­bero poi sfrut­tate; ora sono spesso le appli­ca­zioni di Apple a fare da apri­pi­sta o comun­que a trai­nare e indi­riz­zare l’evoluzione del sistema operativo.

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

È uscita la beta di LaunchBar 5!

Sono un assi­duo uti­liz­za­tore di LaunchBar # e anche se curio­sa­mente non con­trollo mai even­tuali aggior­na­menti, appena vengo a cono­scenza di qual­che novità corro subito ad instal­lare l’ultima versione.

Le novità più rile­vanti sono:

1. cro­no­lo­gia archi­vio appunti;
2. sup­porto per Quick Look;
3. le azioni;
4. la cal­co­la­trice.

Cronologia archi­vio appunti

Una delle man­canze più sen­tite in Mac OS X è la man­canza di un equi­va­lente del kill ring di Emacs, in modo da poter con­ser­vare più oggetti copiati per un uso futuro. Nell’ultima ver­sione di LaunchBar è pos­si­bile usare la “Clipboard History”; è attiva di default e fun­ziona in modo tra­spa­rente, memo­riz­zando ogni ope­ra­zione di copia (fino a un mas­simo di quaranta).

Il con­te­nuto è dispo­ni­bile con tre com­bi­na­zioni da tastiera ma, in linea con la filo­so­fia di fondo LaunchBar cerca di eli­mi­nare il più pos­si­bile dei pas­saggi inu­tili. Non solo è pos­si­bile richia­mare la sto­ria dell’archivio appunti per poi sele­zio­nare, dando invio, l’elemento voluto, ma pos­siamo anche sce­glierlo diret­ta­mente al rila­scio del tasto, defi­ni­bile, di selezione.

Supporto per Quick Look

Adesso è pos­si­bile visua­liz­zare l’anteprima dei docu­menti diret­ta­mente da LaunchBar, con le stesse abbre­via­zioni che si usano nel Finder. 

Le azioni

L’architettura è stata rivi­sta e ne sono state aggiunte molte altre. Adesso è suf­fi­ciente met­tere le pro­prie azioni in ~/Library/Application Support/LaunchBar/Actions per­ché ven­gano rile­vate dall”applicazione. 

Inoltre ven­gono indi­ciz­zati anche i ser­vizi. Vediamo se comin­cerò ad uti­liz­zarli di più.

Credo che in quest’area QuickSilver rimanga comun­que supe­riore, per­ché è più chiara la con­ca­te­na­zione delle azioni. 

La cal­co­la­trice

Con que­sta release, è dif­fi­cile tro­vare un motivo per usare una delle varie cal­co­la­trici dispo­ni­bili come wid­get. Adesso sono dispo­ni­bili le fun­zioni scien­ti­fi­che più comuni, con tanto di abbre­via­zioni (ad es. sin(33) può essere scritto come S33), ed è anche pos­si­bile esten­dere le fun­zio­na­lità con delle macro.

Ispirato da que­sto post di Tim Bray, ecco qual­che nota su come uso attual­mente Mac OS X e le varie appli­ca­zioni, in par­ti­co­lare per i punti in cui trovo dif­fe­renze interessanti.

Setup gene­rale

La mia mac­china di lavoro attuale è un MacBook ma uso ancora un iMac della penul­tima gene­ra­zione per varie cosette, tutte piut­to­sto fri­vole. Per ren­dere l’idea, le appli­ca­zioni 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 tro­vare molto comoda la divi­sione dei com­piti fra la due mac­chine. Il MacBook signi­fica più o meno lavoro, l’iMac signi­fica più o meno ricrea­zione. Questa divi­sione mi ha anche aiu­tato a dare un taglio netto alle vec­chie abi­tu­dini di comin­ciare la gior­nata con il cap­puc­cino e la brio­che dell’internauta: email e web. Sbrigo la posta di lavoro in due o tre momenti chiave della gior­nata e lascio alle fasi serali le mai­ling list e i feed RSS.

La con­di­vi­sione dei dati

Il dilemma dell’avere una o più mac­chine è sem­pre legato ai dati e al loro accesso. Tim Bray nel suo post sot­to­li­nea i van­taggi della mac­china unica e non ha torto. Nel mio caso, vista la ripar­ti­zione degli usi, la que­stione è meno sen­tita. In ogni caso, la sin­cro­nia fra la due mac­chine non è un pro­blema: tutti i pro­getti impor­tanti sono in Subversion; il bri­co­lage sta tutto su MobileMe; i book­marks sono su Delicious.

Entro la fine dell’anno por­terò tutti gli arti­coli ancora rile­vanti in Evernote e tutti gli altri docu­menti su MobileMe. Vorrei anche spo­stare la libre­ria di iTu­nes su un ser­ver in LAN, un Mac Pro che ospita anche la repo di Subversion, i bac­kup di Time Machine, data­base, ecc ecc.

Una cosa che non ho e che invece è di fon­da­men­tale è un moni­tor esterno. Il van­tag­gio di pro­dut­ti­vità è inne­ga­bile, senza cal­co­lare la posi­zione di lavoro ecc.

Organizzazione dei documenti

Questo è la parte del post di Tim Bray che mi ha dato il vero sti­molo per scri­vere que­sto post. Quando ho letto che orga­nizza i file per data sono rima­sto un po’ per­plesso. Premetto che sicu­ra­mente avrà un sacco di file in più dei miei quat­tro ma ho la sen­sa­zione che il mio sistema potrebbe fun­zio­nare anche nel suo caso.

Qual è il mio “sistema”? È pra­ti­ca­mente ine­si­stente: tranne che per qual­che file par­ti­co­lar­mente usato butto tutto nella car­tella dei docu­menti e lo cerco con spo­tlight. Fine della sto­ria. Lo stesso vale per la posta elet­tro­nica, dove ho una sola car­tella di archi­via­zione, per la posta di lavoro. Le mai­ling list hanno le loro car­telle e ven­gono svuo­tate perio­di­ca­mente da uno script in perl che le passa in ras­se­gna, eli­mi­nando i mes­saggi più vec­chi di 15 giorni.

Il dock. Cos’è il dock?

Anche que­sto mi ha fatto sor­ri­dere. Anch’io, come Tim Bray, tenevo il dock sulla destra, sem­pre visi­bile. Adesso l’ho ripor­tato sotto ed è nasco­sto. 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 car­telle ma rimane una cosa a cui potrei rinun­ciare. Al pari di altre idee, come Spaces, il Dock è stato tanto una fol­go­ra­zione alla prima demo e un non-evento nell’uso con­creto. Non è cha sia stato deluso al con­tatto diretto: sia il Dock che Spaces fanno quanto pro­messo ma sem­pli­ce­mente non li ho tro­vati utili.

Il ter­mi­nale

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

Direi che mi sono dilun­gato fin troppo… E pen­sare che non ho preso in con­si­de­ra­zione l’iPhone!

Noto con pia­cere (e con un po’ di invi­dia) che Laburno si è com­prato il nuovo MacBook e che ne sem­bra molto sod­di­sfatto; ed è anche diven­tato un uti­liz­za­tore di Coda.

Ragion per cui segnalo que­sto truc­chetto, pro­prio per Coda, per aggiun­gere nuove refe­rence a quelle già esi­stenti.

Avendo migrato qual­che giorno fa i miei pro­getti in Trac da FreeBSD a Mac OS X, avevo deciso di usare l’open direc­tory per l’autenticazione, così, tanto per gra­dire. Tutto bene.

Oggi, improv­vi­sa­mente, gli utenti non rie­scono più ad auten­ti­carsi. Per motivi ancora tutti da accer­tare Kerberos ha smesso i fun­zio­nare. Panico: la cura stan­dard per pro­blemi del genere è la reinstallazione.

Poi mi sono ricor­dato che ho ese­guo dei bac­kup gior­na­lieri di tutta l’Open Directory. Il tempo di indi­care il disco imma­gine, inse­rire la pas­sword e tutto è tor­nato come prima.

La parte mezza vuota del bic­chiere è che Open Directory non dovrebbe essere così deli­cata, la parte mezza piena è un sabato mat­tina dedi­cato a cose più produttive ;-)

Per ragioni sto­ri­che (con la “s” molto minu­scola) molti utenti che attual­mente usano Mac OS X hanno una cono­scenza rela­tiva dell’uso della shell e anche i più bravi hanno comun­que biso­gno di un aiutino.

Nel tempo ho pro­vato diverse solu­zioni per tenere segnati i comandi che, essendo magari usati solo rara­mente, devono ogni volta essere “risco­perti”, ma senza par­ti­co­lare suc­cesso. Quello che suc­cede più fre­quen­te­mente è che non mi ricordo nem­meno di guar­dare (idem con i vari alias).

Adesso ho sco­perto Clix e sono curioso di vedere se può miglio­rare qual­cosa. L’applicazione è molto sem­plice: dopo aver creato un nuovo file in cui sal­vare i comandi, ne aggiun­giamo uno con ALT-CMD-RET e com­pi­liamo le infor­ma­zioni necessarie:

Form per l’aggiunta di un comando

 Fatto que­sto pos­siamo lan­ciare il comando ed even­tual­mente copiarne il risultato:

Esecuzione del comando

Non male, vero?

Non so bene come valu­tare l’ultimo periodo per Apple. Da una parte gli affari vanno bene (1, 2) ma dall’altra sono stati com­bi­nati diversi casini: la tran­si­zione a MobileMe; la qua­lità di MobileMe stesso; la que­stione della salute di Jobs; infine, l’attesissima patch con­tro l’inquinamento della cache (cache poi­so­ning) del DNS.

Non cono­sco i det­ta­gli spe­ci­fici di que­sta ver­sione ma, par­lando in ter­mini gene­rali, il cache poi­so­ning con­si­ste nel fare in modo che, quando inter­ro­ghiamo il DNS per chie­dere a quale indi­rizzo IP cor­ri­sponde un certo nome di domi­nio, come ad es. refactor.it, non otte­niamo in rispo­sta l’indirizzo cor­retto ma un altro, con­sen­tendo in que­sto modo all’autore del cache poi­so­ning di indi­riz­zare gli ignari utenti su siti che nulla hanno a che fare con quelli veri: voi pen­sate di acce­dere al vostro conto in banca e in realtà dall’altra parte c’è già qual­cuno che si frega le mani (sì, lo so che state pen­sando che non è poi così diverso dal ban­chiere ma è per ren­dere l’idea).

Ora, come spesso suc­cede, que­sta vul­ne­ra­bi­lità è stata sco­perta molto tempo fa (circa sei mesi) e il respon­sa­bile, Dan Kaminsky, ha tenuto segreta la cosa dando così il tempo di tro­vare il rime­dio. Come altret­tanto spesso suc­cede, la noti­zia è tra­pe­lata ed è scat­tata la corsa fra i cer­ca­tori del rime­dio e i cer­ca­tori del rag­giro. (3)

In tutta que­sta tra­fe­lata corsa nel rimet­tere insieme i cocci, chi è rima­sto cla­mo­ro­sa­mente indie­tro è stata Apple, che solo ieri ha rila­sciato la patch e solo per Mac OS X Server. È pro­ba­bile che la causa di que­sta len­tezza sia legata al pro­cesso di con­trollo qua­lità a cui sono sot­to­po­sti gli aggior­na­menti soft­ware ma ciò non toglie che Apple non è stata in grado di rea­gire in modo tem­pe­stivo e que­sto va cor­retto, altri­menti il mer­cato enter­prise rimarrà sem­pre in mano ad altri e per buoni motivi.

Altri link:

• “DNS Clients Have Small Vector of Risk after Patch”: un bel post sulle pro­ba­bili cause del ritardo, sulla sua gra­vità e sui pos­si­bili rimedi da uno che in Apple ci ha lavorato;
• “Opinion: Apple’s unfor­gi­va­ble DNS delay”: cri­tica severa ma giu­sta su tutto l’affaire;
• “The DNS Vulnerability”: cito di nuovo que­sto arti­colo per­ché nella seconda parte offre spunti anche per una cri­tica più radi­cale a tutta le que­stione della sicurezza.