Durante questa settimana un po’ tutti i media non hanno lesinato elogi di fronte alla filantropica iniziativa di Mark Zuckerberg internet.org, ma quanto c’è veramente di filantropico dietro a questa mossa?

Vediamo di capirci un po’ meglio, partiamo dal presupposto che questa iniziativa sia veramente filantropica, insomma una roba alla “one laptop per child” che permetta alle popolazioni che vivono in paesi economicamente svantaggiati di acculturarsi e migliorare la propria vita o la società in cui vivono.

Prendiamo quindi ad esempio la nostra società, che bene o male questi mezzi già li possiede (più o meno…) e osserviamo quanto il web migliora la nostra vita; certamente è uno strumento utile, ci permette di raggiungere informazioni di cui non eravamo a conoscenza, ci permette di partecipare e di contribuire a questa “conoscenza globale” sottoforma di post sui blog, di interventi sui forum, di discussioni sui newsgroup.
Ma in realtà quante delle attività online sono finalizzate a tutto questo?

Qual’è invece il peso delle attività futili, certamente divertenti, ma scarsamente educative o comunque migliorative della nostra condizione di esseri umani?
Tutti i milioni di utenti che popolano i social network e che si scambiano miliardi di informazioni sottoforma di brevi messaggi da 160 caratteri, immagini più o meno divertenti, fotografie taggate e click su “mi piace”, quanto sono significativi in termini di contributo all’umana evoluzione? Qual’è il peso di un post su twitter o di una foto taggata rispetto chessò ad un post di un paio di pagine su un blog?
Per carità, anche il post su un blog o una discussione su un forum può essere frivola, divertente e intellettualmente non elevata, ma presuppone una attività partecipativa che comporta una riflessione.

Se poi andiamo a vedere le statistiche scopriamo che la propensione a intraprendere attività intellettualmente stimolanti online è fortemente influenzata dalla classe sociale in cui si è cresciuti e dove si vive, quindi in parte anche dal livello di istruzione e dalla curiosità intellettuale che anima gli individui in questione.
Se guardiamo i dati il gap tra gruppi con differente livello di scolarità è pressochè costante, al contrario la diffusione di connettività broadband e dispositivi tecnologici che permettono accesso alla rete è talmente pervasiva ed esponenziale da aver praticamente saturato il mercato invadendo qualsiasi fascia di reddito o gruppo sociale.

Quindi se la diffusione capillare della tecnologia non ha sostanzialmente migliorato le condizioni di vita nel mondo occidentale, perchè dovrebbe farlo in paesi dove i problemi principali sono la scarsità di acqua potabile, di cibo, di strumenti per lavorare e di scuole?
Siamo proprio convinti che un tablet o uno smartphone connessi al web a qualche decina di Kbps siamo risolutivi?
Non è forse più ragionevole pensare che sia prioritario fornire i mezzi di sostentamento necessari, migliorare il livello di istruzione e forse POI fornire accesso al web in modo da sviluppare quelle attività intellettualmente stimolanti che possono portare a una maggiore consapevolezza dei problemi di ciascuna comunità?

In realtà Zuckerberg e i suoi compagni di merende sono solo alla spasmodica ricerca di nuovi mercati da cui attingere utenti per i loro servizi (senza i quali chiuderebbero prima di subito), possibilmente attraverso dispositivi che meglio si adattano ai loro servizi, ovvero smartphone e tablet.
Non è un caso che gli strumenti prediletti siano questi, dispositivi scarsamente interattivi e generalmente usati in modo molto passivo, perfetti per postare brevi messaggi (non certo per scrivere un lungo e noioso post come questo) o per fare browsing, gli strumenti perfetti per definire se stessi sulla base di parametri comprensibili dal mercato (sei single, accoppiato o in cerca di partner? quali libri ti piacciono? quali film ti piacciono? etc etc etc…), guardacaso l’obbiettivo di società che vivono di data mining come Facebook o Google.

Non solo, alla base di tutto questo vi è una dottrina molto popolare in California che risponde al nome determinismo tecnologico, che vede nella tecnologia la via maestra per risolvere tutti i problemi (sociali, politici, economici etc etc) del pianeta, basti pensare che qualche invasato di questa scuola di pensiero è arrivato a teorizzare che con un manuale di javascript da 100 $ un homeless potrebbe arrivare a risollevarsi e migliorare la propria condizione di vita…

Qui il cerchio si chiude, io non giudico negativamente Zuckerberg o suoi sodali per il tentativo di espandere i loro potenziali utenti (qualcuno ha detto prodotti?), non sopporto però che tutto questo venga mascherato da iniziativa filantropica, perchè è falso e vergognoso nei confronti di coloro che vivono in condizioni di totale povertà, spesso a causa degli interessi occidentali.

Dalle analisi degli accessi noto con grande piacere che c’è sempre grande interesse riguardo ai server domestici, se preferite “muletti”.

Di recente il mio storico Epia 5000A ha subito un brutto colpo, una serie di guasti allo storage l’hanno costretto ad un down forzato, vista poi la difficoltà a reperire hard disk PATA sono stato costretto ad acquistare un adattatore IDE-SATA il quale a sua volta mi ha costretto a ritrasferire l’Epia nel primo storico case a causa di problemi di spazio (fisico stavolta).

Naturalmente nessun dato è stato perso grazie ai rigorosi piani di backup che ho implementato nel tempo, questa pausa però mi ha spinto a riflettere un po’ sul futuro del mio server domestico.
In tal senso l’esperienza con Raspberry PI è stata illuminante, le possibilità software sono pressochè le stesse del mio Epia x86, l’assorbimento è di gran lunga inferiore (meno di 1/5 in idle, addirittura circa 1/9 a pieno carico), la temperatura da dissipare pressochè trascurabile, gli ingombri ridottissimi, le performance simili.
L’unico aspetto limitante di Raspberry PI è lo storage, dover ricorrere ad un disco usb alimentato mediante un hub usb rappresenta un vero scoglio, o per lo meno trasformerebbe quello che oggi è un bel case ordinato e compatto in una foresta di mangrovie di cavi.

Una soluzione ci sarebbe, si tratta del progetto Fairywren, una mainboard mini-itx a cui connettere Raspberry PI con tutto l’occorrente per storage, rete, alimentazione, hub usb interno, un piccolo gioiellino che sta nascendo su Kickstarter e che rappresenterebbe una vera manna per chi come me vorrebbe usare Raspberry come server domestico.

Frequentando vari forum però mi è stato giustamente fatto notare che al di la dell’hype generato dal progetto Raspberry PI è basato su un SoC relativamente antiquato e piuttosto limitato in termini di risorse, idem per quanto riguarda progetti simili tipo BeagleBone.
Così sono venuto a conoscenza di altri progetti molto più interessante, magari meno rivolti alla ricerca o alla sperimentazione ma dotati di più risorse, insomma il perfetto punto di contatto tra le esigenze server e i vantaggi delle architetture ARM.

Due hanno attirato la mia attenzione, entrambi dotato di SoC Cortex A20 dual core, entrambi dotati di 1GB di ram DDR3 e un canale SATA, si tratta di:

Cubieboard 2

Olimex A20-OLinuXino-MICRO

Entrambi ottimi progetti, simili dal punto di vista hardware ma differenti come approccio e filosofia di base.
Cubieboard 2 ha al suo attivo una comunità abbastanza diffusa, un forum piuttosto popolato e un layout piuttosto compatto, OLinuXino A20 è meno diffuso, un layout più “affollato”, una comunità meno popolosa ma è dotato di un gran numero di interfacce GPIO (quindi molto più indicato per la ricerca e applicazioni pratiche, un approccio simile a Raspberry PI per intenderci), entrambi sono progetti open hardware.

Di per se sarei fortemente attratto da entrambi questi progetti, l’unico aspetto che mi lascia dubbioso è il layout di questi sistemi, bellissimo e compatto ma difficilmente integrabile con un case ordinato e altrettanto compatto, insomma se dovessi utilizzarli mi ritroverei con una foresta di mangrovie di cavi come con Raspberry PI

Quasi in risposta alle mia suppliche il team di Cubieboard ha annunciato un nuovo progetto open hardware chiamato Cubietruck che prevede:

• SoC A20 Cortex-A7 Dual Core
• 1 o 2 GB di ram
• canale SATA
• interfaccia di rete Gbps

ma soprattutto grande attenzione al layout, tanto da essere sovrapposto a quello di un hard disk da 2.5″, e addirittura pubblicando un prototipo di case veramente fantastico.

Mio al DAY1!!!

[EDIT]

Good news! Sembra che la produzione di Cubietruck stia per iniziare! Yuppi!!!! :)

Della serie “tips & tricks per tutti” parliamo di un’altro semplice trucchetto a costo zero utilissimo per evitare di fare tutte quelle cose che in gergo tecnico e strettamente sistemistico si definiscono MINCHIATE.

Lavorando prevalentemente su console testuali (es terminali virtuali di server GNU/Linux, magari via ssh) capita di aver aperto contemporaneamente parecchi terminali verso diverse macchine.
Lavorare in questo modo presenta innumerevoli vantaggi, è un modo veloce, snello e immediato per poter fare qualsiasi cosa in brevissimo tempo.
Ad un utente comune potrà sembrare arcaico ma vi assicuro che se dovessi riconvertirmi a sistemista Windows impazzirei, o quantomeno sarei molto meno produttivo dovendo tornare ad una interfaccia prevalentemente grafica, non a caso la prima cosa che faccio quando prendo in mano una macchina Windows è installare cygwin e OpenSSH.

A questo dettaglio tecnico aggiungete la classica disorganizzazione e arroganza del cliente tipico italiano (già, proprio quello che pretende le cose fatte “per ieri”), le offerte folli dei commerciali (avete presente l’espressione “vendere la pelle dell’orso prima di averlo ucciso”?), il caos imperante in qualsiasi CED, shakerate bene e otterrete un mix letale di pessime condizioni operative, in questa situazione capite bene che è molto facile confondere un terminale per un altro :(
Provate a immaginare il brivido che vi corre lungo la schiena appena vi siete accordi di aver droppato un database su un server di produzione anzichè quello di test…

Per evitare tutto questo, o per lo meno per renderlo meno probabile basta un semplicissimo accorgimento, personalizzare il prompt del terminale.
E’ sufficiente ad esempio aggiungere una label prima del prompt, magari di un colore differente a seconda della criticità del sistema come in questo esempio

Per fare questo è sufficiente modificare gli script di inizializzazione della bash per il proprio utente oppure per tutto il sistema, esportando opportunamente la variabile PS1 (Default interaction prompt).

Ad esempio per ottenere il prompt visibile nello screenshot su RedHat Enterprise o CentOS è sufficiente esportare la variabile con questo comando:

export PS1='\[\e[1;31m\][!!! PRODUZIONE !!!]\[\e[m\] [\u@\h \W]\$'

Per rendere la modifica attiva ad ogni login è sufficiente modificare gli script di init della bash (es .bashrc o .bash_profile nella propria home directory, oppure /etc/profile o /etc/bashrc, oppure aggiungere uno script in /etc/profile.d/) in modo che la variabile venga esportata come meglio preferite ad ogni login.

Uno degli aspetti che più mi solletica dei server Dell è il loro eccellente parco software, sia per quanto riguarda gli aggiornamenti ma soprattutto riguardo ai sistemi di monitoring.

La punta di diamante del monitoraggio Dell è rappresentata dall’ottimo OMSA (OpenManage Server Administrator), disponibile per quasi tutti i sistemi operativi più diffusi, stabile e relativamente leggero (per lo meno per la disponibilità di risorse attuali).

Uno degli aspetti di OMSA che ho notato mette in difficoltà clienti e amministratori è la notifica di alert via email; l’approccio di Dell a tal proposito è votato alla più totale flessibilità, anzichè dedicare qualche stringata opzione per la definizione di SMTP, sender e destinatari OMSA permette di definire per ciascuna risorsa uno script che viene lanciato ogni volta che si verifica un alert relativo alla risorsa stessa.

Di default le risorse da monitorare non prevedono alcun alert (es Watchdog ASR).

Come vedete nel dettaglio ciascuna risorse prevede la possibilità di lanciare uno script locale.

Se vogliamo inviare una mail lo script è presto fatto.
Nel caso vi troviate a che fare con un server Windows basta utilizzare l’ottimo blat, potete prendere ad esempio lo script che ho utilizzato per la schedulazione di clamwin.
Per server con distribuzione GNU/Linux la soluzione è ancora più semplice, basta un banale script bash per inviare mail tramite il comando mail (es /etc/Dell/mail.sh).

#!/bin/sh
TESTO="Verificare lo stato del server"
echo $TESTO | mail -s "[OMSA] PROBLEMA SERVER" [email protected],[email protected]

Una volta creato lo script ricordate di dargli diritti di esecuzione (chmod +x /etc/Dell/mail.sh), nel caso dobbiate utilizzare un altro server per il relay SMTP fate riferimento alla documentazione dell’MTA utilizzato (es sendmail piuttosto che postfix).

Ora viene la parte pallosa, Dell OMSA prevede una serie di servizi per cui attivare le notifiche (giusto come esempio 34 su PowerEdge 2950, 38 su un R710), definirli uno a uno è un lavoro palloso, che diventa impossibile nel caso di troviate a che fare con decine di server.
Per fortuna ci viene in aiuto il set di utility command line di OMSA, con il comando “omreport system alertaction” potete verificare lo stato dei servizi.
Con il comando omconfig potete configurare tutti gli alert con un singolo comando sfruttando le poderose features della bash:

for device in $(omconfig system alertaction -? | grep "event=" | \ 
cut -d'=' -f 2 | awk '{print $1}') ; \
do omconfig system alertaction event=$device \ 
execappath=/etc/Dell/mail.sh ; \
done

Ecco fatto, gli alert per tutti i servizi sono configurati, non vi resta che tenere d’occhio la vostra email nella malaugurata ipotesi si rompa qualcosa.

E non lesinate sui contratti di supporto!!! :O