Chi è utente Mac da qualche tempo credo conoscerà il Magic Mouse e il Magic Trackpad di Apple. Non sono altro che un mouse e un trackpad (allargato) aventi capacità multi-touch, ovvero in grado di riconoscere il contatto di più dita. Questa funzionalità migliora di parecchio l’esperienza utente, in quanto consente di compiere azioni molto spesso ripetitive con una facilità e rapidità incredibili, quali ad esempio l’andare avanti e indietro con il Finder o con il browser Internet, oppure lo scorrimento orizzontale dei documenti, lo zoom e così via… Questo a mio avviso è un modo intelligente di portare la “tecnologia touch” sui computer visto che l’utente non viene affaticato, mentre se si dovesse utilizzare un computer toccando lo schermo… beh ci si stancherebbe subito a forza di tenere il braccio teso.

Vabbè insomma, detto questo il problema è che le azioni che di “default” è possibile effettuare con le periferiche di input sopra citate sul Mac, sono obiettivamente limitate. Per sbloccare il loro “potenziale nascosto” ci viene in soccorso l’utility gratuita BetterTouchTool, sviluppata da Andreas Hegenberg. L’applicazione è facile sia da installare che da utilizzare e supporta sia il Magic Mouse che il Magic Trackpad oltre a tastiera e mouse generici. Nella prima schermata “Gestures” è possibile associare i gesti alle azioni. Tali associazioni possono essere globali, ovvero utilizzabili indipendentemente dall’applicazione attiva in quel momento; oppure specifiche per ciascuna applicazione. Il numero di gestures disponibili è enorme: circa 40; e ad esse è possibile sia associare una delle azioni predefinite che il programma mette a disposizione o addirittura una combinazione di tasti.

Sono presenti inoltre altre impostazioni (Action Settings) riguardanti ad esempio lo spostamento e il ridimensionamento delle finestre; e le impostazioni avanzate dove è possibile ad esempio aumentare la velocità del mouse rispetto a quella massima consentita o addirittura selezionare l’area del mouse sensibile al tocco. Insomma le possibilità di personalizzazione sono davvero elevate, quindi lascio a voi il compito di provare tutte le impostazioni che fanno al caso vostro.

Vi è mai capitato che un vostro amico o parente avesse qualche problema con il computer e chiedesse il vostro aiuto, ma voi (per vari motivi), non avevate la possibilità di operare direttamente su quel computer? In questo caso l’unico modo per cercare di risolvere il problema del vostro amico, è quello di provare a farsi descrivere il problema via telefono e guidarlo a distanza nella risoluzione. Questo presuppone un ottima conoscenza del computer su cui si è verificato il problema, inoltre con questo metodo si perde molto tempo per far svolgere anche semplici azioni alla persona che ha richiesto assistenza.

Da quando sono entrato nel mondo Mac, ho sempre apprezzato, su iChat, la funzione di “condivisione dello schermo remoto”, che consente di operare su un computer remoto come se ci si fosse fisicamente davanti. E’ chiaro che può utilizzare questa funzione solo chi ha un Mac e un account iChat, ma gli utenti che posseggono questi requisiti sono veramente pochi rispetto alla totalità degli utenti pc. Si potrebbe allora utilizzare il protocollo VNC ma gli svantaggi, credo siano la poca facilità di installazione di un server con questo protocollo, e versioni gratuite prive di supporto alla crittografia dei dati con evidenti rischi per la sicurezza.

La soluzione che ho trovato, e che consiglio si chiama TeamViewer. Una volta scaricato è possibile scegliere se installarlo o semplicemente eseguirlo. In un unico eseguibile sono presenti sia il client che il server. Non sto qui a spiegare come funziona visto che nel sito è spiegato molto bene. Questo programma non offre solo il controllo remoto di un computer ma anche il trasferimento file. I punti di forza di questo software a mio parere sono:

• semplicità di installazione
• versione gratuita per utenti privati
• crittografia della connessione a 256 bit
• multipiattaforma (Windows, Linux, Mac, iPhone, iPad)
• funziona anche dietro un firewall (ergo non bisogna riconfigurare il firewall se presente)

Ho scoperto che esiste un modo per avviare esclusivamente Xbmc senza avviare Gnome o un qualsivoglia ambiente desktop. Esiste infatti la sessione Xbmc. Per avviare tale sessione al posto di quella di default (Gnome, Kde, FluxBox…) è sufficiente creare o modificare il file “.xinitrc” che si trova nella directory home dell’utente e inserire il comando

xbmc –standalone

In questo modo le risorse del sistema verranno utilizzate principalmente solo da Xbmc con un aumento delle prestazioni visto che l’ambiente desktop non è più in esecuzione.

Se volete approfondire ecco un link utile

My Ubuntu Based XBMC/HTPC with full autostartup

Provando Ubuntu 10.04 mi son detto “Wow riconosce al volo la pennina wireless, non dovrò più rompermi a installare i driver Windows tramite Ndiswrapper“. Quando però ho aggiornato il server sono cominciate le rotture di scatole. All’inizio la pennina wireless non veniva riconosciuta a causa di un conflitto tra i driver installati da me e quelli nativi nel nuovo sistema operativo. Allora ho rimosso i vecchi driver e ho lasciato quelli nativi. La pennina ha ripreso a funzionare.

Se non che, dopo qualche giorno, mi sono accorto che il server si era scollegato dalla rete wireless e non si era più ricollegato da solo. Vado a vedere, e per Wicd il computer risultava ancora connesso. Il problema continuava a verificarsi e dopo infinite ricerche su Google ne è saltato fuori che i driver nativi sono buggati, e che quelli che erano installati prima erano migliori:

Device has tx/rx stalls on poor links (less than ~30/100), workaround is present in driver (when link quality less than 30%, issue scan every 0.5sec, which releases freeze). Performance is not pair with ndiswrapper+windows driver in this case. Stalls might be happening on better links too but much more infrequently and recover much faster. Stalls do not happen using ndiswrapper, so there might be some stricter tx/rx locking present in windows driver that prevent stalls.

Peccato che il “workaround” nel mio caso non funzioni. Allora ho provato a togliere i driver nativi e reinstallare i driver precedenti ma non c’è stato verso di farli funzionare. Così ho ripristinato i driver nativi, e visto che il controllo dello stato della connessione non funziona (il server risulta sempre connesso), ho deciso di implementare uno script in bash che controlli decentemente se il computer è connesso o no, e in caso negativo svolga le operazioni necessarie per riconnetterlo.

!/bin/bash

if !(ping -c 1 -w 3 www.google.it > /dev/null)

then

# echo “Server disconnesso. Disattivo e riattivo interfaccia.”

ifconfig wlan0 down

ifconfig wlan0 up

fi

A questo punto basta impostare l’esecuzione dello script ogni minuto con Cron ed il gioco è fatto.

Già che ho aggiornato il server da Ubuntu 8.04 a 10.04, ho pensato bene di ridurre il carico di lavoro del computer eliminando i processi superflui. Usando il server anche come media center lasciavo sempre in esecuzione Gnome in modo che fosse pronto a far partire Xbmc quando serviva, a portata di telecomando. Di fatto il tenere in esecuzione Gnome tutto il tempo implica anche l’esecuzione di tutti i processi ad esso relativo che inevitabilmente appesantiscono il server.

L’idea è quella di avviare Gnome esattamente quando serve, come già facevo con Xbmc. Occorre quindi:

1. disabilitare gdm
2. loggare automaticamente all’avvio l’utente nella Bash, che deve eseguire Gnome e Xbmc
3. riconfigurare il server X per consentire l’esecuzione a tutti gli utenti
4. configurare i tasti del telecomando per avviare e terminare Gnome e Xbmc da quest’ultimo
5. eseguire automaticamente irexec (esegue comandi impartiti da un telecomando ir) al login dell’utente
6. impostare l’avvio di Xbmc all’avvio di Gnome

Bene si può cominciare.

Punto 1: da root, nel file /etc/init/gdm.conf sostituire le linee

start on (filesystem

and started dbus

and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1

or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1

or stopped udevtrigger))

con

start on runlevel []

Punto 2: da root nel file /etc/init/tty1.conf modificare l’ultima linea (dove USERNAME è il nome dell’utente che deve loggare) con

exec /bin/login -f USERNAME < /dev/tty1 > /dev/tty1 2>&1

Punto 3: da root eseguire il comando

dpkg-reconfigure x11-common

e selezionare “Chiunque” per chi ha il permesso di avviare il server X

Punto 4: per configurare il telecomando bisogna editare il file .lircrc presente nella home directory dell’utente. Se non sapete cos’è Lirc date un’occhiata qui. Il comando per avviare il server X e Gnome è

startx

mentre per terminarli

gnome-session-save –force-logout

Questi comandi vanno inseriti nel modo appropriato nel file .lircrc .

Punto 5: aggiungere alla fine del file .profile nella home dell’utente la linea:

irexec &

Punto 6: in Gnome basta andare su Sistema -> Preferenze -> Applicazioni d’avvio, e da li aggiungere il comando “xbmc” nell’elenco tramite il tasto aggiungi.

Al riavvio troveremo solo un’interfaccia riga di comando che occuperà pochissime risorse, ma quando ne avremo bisogno basterà premere un tasto del telecomando per avviare il nostro media center con interfaccia grafica; ed un altro tasto per tornare alla riga di comando. Con questa soluzione ho decrementato sensibilmente il numero dei processi in esecuzione: da 160 a 110 circa.

Fonti:

http://tombuntu.com/index.php/2010/01/01/enable-automatic-login-in-ubuntu-9-10-server/

http://ubuntuforums.org/showthread.php?t=1477439

http://ubuntuforums.org/showthread.php?t=255148

http://www.cyberciti.biz/tips/linux-desktop-how-to-shutdown-restart-or-logoff-gnome-via-commandlauncher.html