Mi rendo conto solo ora che è passato quasi un secolo da quando presentai su questo blog il mio leggendario server domestico basato su Via Epia.

Da allora la mia attenzione in questo campo è aumentata in modo esponenziale e dopo elocubrazioni varie ho varcato la soglia del mondo ARM con Raspberry PI.
Sia chiaro, considero Raspberry PI un progetto STUPENDO e RIUSCITISSIMO, sia dal punto di vista tecnico che di comunicazione, tant’è che ne ho comprati ben due e l’ultimo di questi mi sta fedelmente servendo da parecchio tempo.

Ciò nonostante le limitazioni di Raspberry PI sono palesi, tecnicamente e anche eticamente (etica informatica? Già, perchè no?).
Tecnicamente parlando il SOC di cui è dotato è parecchio datato e poco potente, ottimo per tantissime attività ma dalle performance scarse in molti campi (ad esempio come nas o backup repository, come webserver o application server).
Inoltre bisogna ammettere che il sottosistema di I/O è progettato piuttosto male, tant’è che una delle più frequenti cause di problemi è proprio il controller USB su cui ricadono sia la scheda di rete (a 100 Mbps) che le porte USB, unica connessione disponibile per storage capiente e alternativo alla scheda SD.
Io stesso sono stato costretto a pensionare il mio primo esemplare a causa del controller USB che una volta posto sotto stress disconnetteva il device USB corrispondente al disco esterno da 2.5″ dove risiedono i miei file.
Dal punto di vista etico invece non posso fare a meno di notare la stridente contraddizione di un progetto che ha fatto della filosofia Open Source la sua bandiera, ma che di fatto è fortemente “closed”, tant’è che ad oggi non sono stati resi pubblici gli schemi dell’hardware stesso.

Visto il successo di questo progetto è bastato poco perchè nascessero molte iniziative simili, alcune con tutti i requisiti tecnici per surclassare Raspberry PI (una molto interessante ma dal costo esageratamente elevato è Cubietruck di cui avevo già parlato).
Per fortuna alcune di queste si sono consolidate, hanno creato una discreta comunità di utenti e, cosa che non guasta mai, hanno proposto le loro soluzioni a prezzi accessibili; tra queste le principali sono Banana PI e le board Olimex (delle quali la più interessante ad oggi è la Lime2).

Tecnicamente si tratta di due progetti molto simili, basati entrambi su SOC ARM Cortex-A7 dual-core (Allwinner A20), 1GB di ram, controller SATA, scheda di rete gigabit ethernet e prezzo tutto sommato allineato (circa 45 euro); rispetto a Raspberry PI la potenza computazionale e le performance di I/O sono sbalorditive, e nonostante questo l’assorbimento è persino più basso.
Anche eticamente le due schede sono simili, di entrambi infatti sono disponibili i sorgenti e tutta la documentazione.

Come è intuibile dal titolo ho scelto Banana PI, ero molto incuriosito dal prodotto Olimex ma la disponibilità da Amazon mi ha fatto propendere per il concorrente; oggi poi mi è pure stato recapitato il case in plexiglass con relativo cavo SATA (con alimentazione integrata), per cui quale migliore occasione per immortalare questo magico scatolino?

A breve mi aspetta una colossale migrazione (lavorativa), appena avrò finito e sarò riuscito a tirare un po’ il fiato procederò con la migrazione (domestica) del muletto al nuovo Bananone :)

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!!!! :)

Mi capita abbastanza frequentemente di discutere di software open source e uno dei dubbi che spesso sorgono è come contribuire ad un progetto.

Il modello di sviluppo open è una realtà che oggettivamente ha cambiato l’information technology, questo è un dato di fatto incontrovertibile, ed è un fenomeno sorprendente sia dal punto di vista tecnico che sociale.
Basta provare a lavorare in gruppo per un qualche ora per rendersi conto di quanto sia difficile coordinarsi e fare davvero “team”, già perchè è facile scrivere sul CV cazzate false tipo “ottima predisposizione al lavoro di gruppo”, un altro paio di maniche è metterlo in pratica, figuriamoci quando il gruppo è distribuito su un intero pianeta e composto dal più ampio e variegato campionario umano.

La domanda che però molti si pongono è come contribuire concretamente ad un progetto che ci sta particolarmente a cuore, oppure che semplicemente ci è risultato utile.
Dal punto di vista tecnico lo sviluppo di un progetto è una attività complessa che richiede competenze specifiche che solo una percentuale ridottissima degli utenti possiede; poi ci sono altri compiti altrettanto utili e meno impegnativi dal punto di vista tecnico (test, traduzione di documentazione, moderazione di forum e mailing list, creazione di how-to e guide di vario tipo) ma anche questi non sempre sono alla portata di tutti, quantomeno non della maggior parte degli utenti.

Ci sono però due altre cose che un progetto open-source necessità e su cui tutti possono impegnarsi:

1. pubblicità
2. risorse (banda e storage)

Riguardo alla prima c’è poco da dire, non perchè sia poco importante (anzi!) ma perchè è abbastanza autoesplicativa, riguardo al punto due invece qualche considerazione possiamo farla.

Anni fa i progetti open source venivano distribuiti mediante mirror, ovvero server che venivano aggiornati con i rilasci del progetto e che mettevano a disposizione spazio e connettività per permettere alla comunità di scaricare i file e poter beneficiare dei software.
Chiaramente nell’era delle connessioni analogiche (ricordate il vecchio modem 56k?) tutto questo era ad esclusivo appannaggio di pochi, principalmente aziende che in cambio di queste risorse venivano citate tra i “contributors” del progetto.

Se ci pensiamo al giorno d’oggi praticamente tutti (digital divide permettendo) godono di una connessione adsl flat con tagli di banda generosi, connessioni che generalmente sono inutilizzate per la stragrande maggioranza del tempo.
Come se non bastasse oggi esistono sistemi (il celebre Raspberry PI ne è un esempio) dal costo ridicolo (a partire da poche decine di euro) e dall’assorbimento ridottissimo (2-3W per il già citato Raspberry PI, meno di una TV in standby) che sono perfette per questo scopo, a questo aggiungiamo che gran parte dei progetti utilizza come sistema di distribuzione sistemi di file sharing come bittorrent.

Quindi quale miglior modo per contribuire ad un progetto open source offrendo un po’ di banda della propria connessione domestica, magari organizzandosi con dei semplici script per attivare il client bittorrent nelle ore in cui non utilizziamo la linea, siamo fuori casa, al lavoro, oppure semplicemente stiamo dormendo.

Ad esempio con una qualsiasi distribuzione linux e l’ottimo client bittorrent Transmission basta mettere in download una qualsiasi versione di un progetto e lasciare il tutto in seed una volta terminato il download, inserendo dei banalissimi cronjob per arrestare il servizio (schedulato ad esempio quando pensate di tornare a casa dopo una giornata di lavoro, nell’esempio alle ore 19):

00 19 * * * /etc/init.d/transmission-daemon stop > /dev/null 2>&1

e per farlo ripartire (quando generalmente ve ne andate a letto la notte, nell’esempio alle 2):

00 02 * * * /etc/init.d/transmission-daemon start > /dev/null 2>&1

Si tratta di una cosa semplice, alla portata di tutti, che ha un impatto economico ridicolo, ma di grande utilità, pensateci

Ho provato a misurare l’assorbimento elettrico di Raspberry PI.

Con il primo test ho cercato di misurare l’assorbimento elettrico in idle partendo da Raspberry spento ma alimentato, procedendo poi ad un avvio dello stesso fino al termine del boot di raspbian.

Con il secondo test ho cercato di misurare l’assorbimento sotto stress computazionale compilando i sorgenti di Quake 3.

Prossimamente cercherò di effettuare un ulteriore stress test includendo anche la componente GPU, stavo pensando ad una timedemo di Quake 3 (per il rendering 3D) e la decodifica mpeg con qualche filmato.

Finalmente è giunta l’ora! Finalmente il tanto agognato Raspberry PI è arrivato!

Non mi dilungherò sulle caratteristiche dell’oggetto, dato che ormai il progetto ha raggiunto una notorietà tale da non richiedere ulteriori commenti, se non lo conoscete potete trovare tutte le informazioni sull’ottimo sito ufficiale http://www.raspberrypi.org/

Ahimè il mio esemplare (che ho prontamente ribattezzato KenderPI) risulta essere dotato di 256MB di ram contro i 512MB dei nuovi modelli, non mi sarebbe dispiaciuto ricevere il nuovo modello, ciò nonostante posso comunque considerarmi soddisfatto data la lunga attesa (quasi 6 mesi) per poterci mettere sopra le mani e considerando che si tratta di un esemplare perfetto e senza problemi.

L’acquisto è stato fatto tramite il noto sito RS Online (uno dei due distributori ufficiali), dal quale ho ordinato anche un alimentatore micro USB e un case in plexyglass davvero molto carino (giudicate voi dalle immagini).
Per poter operare in totale autonomia poi ho acquistato separatamente l’ottimo cavo HDMI->DVI di Amazon Basic e una SD Sandisk Extreme class 10 45MB/s da 32GB di capacità.

Il feedback iniziale è ottimo su tutti i fronti, Raspberry PI è molto solido e il case che ho acquistato lo rende di fatto indistruttibile e adatto ad essere maneggiato e trasportato in tutta sicurezza, oltre che davvero carino da vedere.
Il cavo acquistato su Amazon è a dir poco perfetto, minima spesa massima resa!
La SD Sandisk per ora si sta comportando bene, voglio effettuare qualche benchmark dettagliato prima di sbilanciarmi in giudizi.

Dal punto di vista software sono rimasto davvero molto colpito da quanto si sia evoluto il progetto rispetto al periodo iniziale.
In passato avevo letto commenti piuttosto critici  riguardo alla fase di setup iniziale del sistema operativo, considerata da molti troppo ostica; l’attuale release di Raspbian (la distribuzione ufficiale del progetto derivata da Debian) invece è estremamente semplice da “installare”, anzi di fatto non si tratta nemmeno di una installazione a tutti gli effetti, dato che basta semplicemente trasferire l’immagine del sistema operativo sulla propria SD, infilarla nell’apposito slot e alimentare Raspberry.

Prossimamente pubblicherò un test su assorbimento elettrico del dispositivo, benchmark relativi allo storage e rete, e un primo test con Quake3! :)