LibreSSL e il porting su altre piattaforme

- Open Source

Finalmente sto iniziando a guardare i primi vagiti di LibreSSL su altre piattaforme, e pur non avendone scritto qui la questione Heartbleed è stata un bel bailamme da seguire, dato che ha tirato in ballo una serie di questioni notevoli sul futuro del software open source e sulla presunzione di sicurezza di alcuni sistemi.

Lock

Sempre per parlare di presunzione di sicurezza, Insane Coder durante un piccolo processo di review di alcuni port di LibreSSL ha effettivamente dimostrato come il grado di sicurezza di LibreSSL diminuisca a seconda della piattaforma utilizzata (il che è anche colpa delle prassi di porting di alcune funzioni); questo non è solo un problema di SSL, ma è anche un campanello di allarme che dovrebbe farci riflettere sulla sicurezza delle piattaforme che usiamo di solito e su cui siamo abituati a sviluppare.

There’s a couple of other significant mistakes I’m expecting to see appear in LibreSSL ports, but have not seen yet. These probably already exists in ports I haven’t reviewed, or will exist in the wild soon enough. Chief among them is implementing timingsafe_bcmp(). I’m expecting to see implementations which directly wrap to regular bcmp(), which unlike the former, is not performed in constant-time, and can expose the application to timing attacks.

Insomma: non è che adesso c’è LibreSSL ed è tutto a posto. Dobbiamo continuare a tenere gli occhi aperti, perché anche se aggiustiamo un anello della catena ci sono due tipi di criticità che si presentano a questo punto.

  • Aggiustare un anello non significa aggiustare tutta la catena: la sicurezza di un particolare strato non assicura che il resto della piattaforma sia a prova di bomba;
  • Inserire un anello nuovo in una catena di tipo diverso è difficile e dev’essere fatto nel modo giusto, garantendo che il risultato non sia troppo debole.

Photo courtesy of Patrick H.

Fotografie da #SOD14, tra dati e tagliatelle

- Open Source

Il weekend che è “appena” (sono ancora in tempo, è venerdì!) passato l’ho trascorso con i miei amichetti di Spaghetti Open Data, a discorrere di dati aperti, apertura di nuovi dataset, e finalmente nuovi bisogni all’interno della community e all’interno della pubblica amministrazione. A #SOD14 abbiamo parlato di OpenStreetMap, di CKAN, e di come un progetto che tira avanti grazie alle contribuzioni (di dati) esterne possa essere facilitato da enti più o meno strutturati ed aderenti a una serie di regole scritte. La burocrazia che non ci piacerà mai troppo poco.

E poi abbiamo sussurrato (non troppo sotto voce) del mitico ed evanescente hackathon alla Camera dei Deputati, che ormai è di dominio pubblico, quindi lo ripeto: si ragazzi, si farà, e sarà una figata. Un po’ meno per noi giudicare che diavolo avrà prodotto la community in meno di 48 ore di sviluppo martellante, ma posso garantire che da lontano si prospetta uno sforzo sicuramente interessante.

Nonostante sia stato meraviglioso ogni momento passato dal sottoscritto al fianco dei compagni opliti lungo la conferenza del venerdì, l’hackathon del sabato (in cui ho contribuito ad Open Data Census – e daje!) ed il momento formativo della domenica in cui ho imparato da Marco Brandizi e Diego Valerio Camarda (più tutta una serie di altre persone, ma Marco era l’eminenza grigia e con Diego ormai siamo amichetti, tollerateci) come diavolo funzionano i linked data, mi sono permesso di prendere qualche appunto sullo stato dell’arte della nostra missione in Italia, di dove siamo e di dove stiamo andando a finire.

Matteo Brunati a #SOD14

2014: la maturità del panorama open data italiano

Al Green Open Data, ormai diverso tempo fa (anni? Non ricordo), mi sono alzato in piedi e ho avuto il coraggio di dire che non bastava liberare dati a caso, ma questi dati dovevano seguire grossomodo delle descrizioni comuni, una notazione omogenea (e qui ci viene incontro l’ambito Linked, me ne rendo conto, ma la facevo più semplice), una serie di regole anche relative alla qualità per cui un diamine di sviluppatore che si trovasse a scremare quella pletora di numeri non dovesse per forza impazzire tra errori umani e insiemi di dati disomogenei.

Beh, improvvisamente non solo la società civile se n’è resa conto insieme a me pian piano, ma addirittura i pubblici amministratori hanno cominciato a capire che favorire il riuso dei dati da parte di una comunità di persone attive non è qualcosa che viene innescato al momento del rilascio, ma segue una dinamica completamente diversa. Allo stesso modo chi prima chinava il capo e ringraziava in maniera quasi fantozziana i liberatori di rumenta selvatica, adesso sta iniziando a farsi sentire, perché effettivamente lavorare su un dato “brutto” significa raffinarlo, portare avanti la ricerca e non poter nemmeno contribuire indietro le modifiche – dato che comunque le istituzioni non sono preparate a gestire un “ritorno” di informazioni di questo tipo – beh, tutto questo significa doppio lavoro per tutti. Ed è interessante (ne sono più che lieto) che anche al secondo raduno storico di Spaghetti Open Data, finalmente, si sia creato il clima per parlare di rilascio in maniera seria, strutturata e tra persone adulte che più che alla visibilità, sono interessate all’effettivo risultato.

Ogni dataset è bello a mamma sua

“Noi abbiamo più dataset” – “Si ma io ho più triple di te” – “Noi abbiamo l’API, l’endpoint SPARQL e pure un kiletto de guanciale”

Ho notato che improvvisamente (o progressivamente durante l’ultimo anno, dipende da quanto granularmente analizziamo il fenomeno) il tema della produzione dei deliverable che affligge chi fa open data si è spostato dall’autoreferenzialità più assoluta, come l’analisi della cardinalità di un linked dataset (quando è linked), all’analisi di cosa produce la liberazione dell’informazione. Questo è interessante, perché ho sentito finalmente pubblici decisori che in veste di civil servant hanno detto chiaramente che è ora di smettere di misurare chi ce l’ha più lungo, e cominciare a fare un lavoro di disseminazione serio.

C’è stato quindi uno spostamento del baricentro, da quanto effettivamente siamo fighi se liberiamo tanti dati, a quanto effettivamente siamo fighi se liberiamo una caterva di cose ma di queste ne vengono usate ben poche – se non nessuna. Finalmente le amministrazioni e anche alcuni evangelist del tema hanno capito che far prender polvere a dei dataset non è bello per nessuno, e hanno cominciato a cercare una soluzione al problema. In sostanza, ogni dataset è bello alla PA sua, ma effettivamente i primi ditini sentenziosi cominciano ad alzarsi, a ragione: come possiamo toglierci da questo impiccio?

Toc toc, sono l’engagement e non cresco sugli alberi

La soluzione principesca venuta progressivamente a galla durante le tappe in giro per Bologna del raduno – tipo alla Pizzeria Il Sellaio, dove fanno una pizza condìta che levati proprio, da leccarsi i baffi – è quella di stimolare gli sviluppatori a produrre prodotti buoni utilizzando i dataset, tramite operazioni di scouting mirato alle community e, perché no, tramite la produzione di esempi facenti uso dei dataset, in modo da produrre un circolo virtuoso in cui lo Stato dà il là, e la società civile in qualche modo risponde con il seguito di un circolo virtuoso che può solo fare benissimo.

Si è capito, quindi, non solo che l’engagement non cresce sugli alberi, ma che fare engagement sul territorio (e non solo) per quanto riguarda i dati è qualcosa di terribilmente complesso, che richiede delle risorse notevoli e che magari non è nemmeno tanto alla portata di un ente come una PA. Code For Italy (tanto per citare un progetto a caso) funge da collante proprio per operazioni come queste, dove un amministratore vuole cercare di coinvolgere quanto più possibile la popolazione in attività sostanzialmente di welfare proveniente dal basso, se vogliamo.

Luca Corsato e Peppa Pig

Master Chef

Durante il raduno, chiaramente mentre ero assente perché mica posso fare sempre il bravo ragazzo, sono stati assegnati dei diplomi di Open Data Master Chef ad un sacco di membri della community che secondo il parere delle teste più anziane hanno dato un contributo rilevante a loro modo (almeno credo) al progredire del gruppo. Sono stato insignito del titolo di Master Chef appena arrivato all’hackathon del sabato, e nonostante poi mi abbiano detto “seh vabbeh tanto l’abbiamo dato a un sacco di gente”, è un onore comunque far parte di Spaghetti Open Data. A #SOD14 abbiamo dimostrato ancora una volta cosa può fare, di cosa è capace una community completamente grassroot come la nostra, capace con la sola forza del numero e della creatività, di tirare fuori costantemente nuovi spunti tecnologici, filosofici, amministrativi.

Allo stesso tempo, in un raduno come #SOD14 è possibile scoprire che le persone hanno anche una faccia. E Luca Corsato ha pure gli adesivi di Peppa Pig attaccati sul computer. Trovarsi di persona è sempre bellissimo, e chiaramente permette anche di accelerare ove possibile il ritmo di produzione di idee e prodotti da parte di una community che, ormai arrivata all’asintoto per quanto riguarda gli utenti a loro modo attivi, ha la necessità di bypassare le fasi in cui si genera più overhead durante le comunicazioni.

Una speranza personale? Ovviamente, che il repository GitHub di Spaghetti Open Data si popoli ancora maggiormente, alla luce anche delle idee emerse durante #SOD14.

Matteo Brunati ha una barba meravigliosa

Nulla mi ha stupito, di #SOD14, più del trovare Matteo ‘dagoneye’ Brunati con una barba che poteva solo raccogliere complimenti. A parte gli scherzi, non solo Matteo mi ha fornito un’interessante ispirazione per il mio look, ma anche un’overview di come funzionano alcuni grossi progetti, come ne è strutturato il workflow, e come vengono ammesse le persone. Tutto materiale per farmi un’idea e decidere insieme alla community nascente cosa diavolo deve diventare Code For Italy (anche se probabilmente lo scopriremo solo vivendo).

Un’ultima parola? Daje.

Shuttleworth, ACPI, e il software proprietario in Ubuntu

- Open Source

Mark Shuttleworth

Nelle ultime ventiquattro ore, niente avrebbe potuto stupirmi più della dichiarazione recente di Mark Shuttleworth (il papà di Ubuntu, per capirci) secondo cui ACPI è il male supremo e non solo: permettere ad una tale tecnologia di venire utilizzata nell’era del software open source (per come la protodefinisce lui) sarebbe un fallimento nostro nel tentativo di smarcarci dai blob proprietari.

In sostanza la sua idea di portare l’innovazione e il codice che la rappresenta direttamente all’interno del kernel Linux, upstream, è ottima, e non la discuto. Un po’di debunking sul suo pensiero però farebbe bene. Mentre lui si proclama paladino dell’open software e in buona sostanza dell’open hardware, gli Ubuntu Phone vengono pianificati dai vendor con un’interfaccia molto simile ad ACPI, dove il kernel è Linux ed è grossomodo upstream, ma i blob proprietari utilizzati sono moltissimi.

We DO live in an era where any firmware code running on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you.

È vero Mark. Hai piuttosto ragione. Mister “Io sono stato sull’Enterprise e voi no” Shuttleworth continua il suo ragionamento in maniera sensata:

If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.

Per estensione, grossomodo, data l’invisibilità del codice sorgente di un software lato server, possiamo desumere che sia legittimo catalogare in questo modo tutto il software proprietario: in mancanza di prove, al posto della presunzione d’innocenza introduci lo scenario nel caso peggiore, in modo da prevedere le conseguenze più brutte rispetto ad un’azione specifica. Bene, tutto giusto.

Se. Se. Se non fosse che Mark “Er Mitico” Shuttleworth ha uno scheletro nell’armadio grosso così, perché installando Ubuntu poi compare questo.

Ubuntu One

Ora, non sta a me definire come il patron di Ubuntu dovrebbe comportarsi, anzi, è bene che dica cose del genere perché sicuramente mi riconosco più in queste frasi che nel comportamento fattivo della sua azienda. Copio da Wikipedia le informazioni che ho su Ubuntu One, che credo siano corrette:

Licenza: il software lato server è proprietario – il software lato client è in GPLv3.

Per carità, tutto bello e tutto figo, Ubuntu One tra l’altro funziona anche bene. Ma le cose sono due. O predichiamo bene e razzoliamo bene, oppure se il software proprietario lo equipariamo ad un malware, allora Ubuntu effettivamente include dei malware, esattamente come professa FSF. Esagero? È probabile. Sono nel torto? Può essere. Ma il fondatore di una compagnia il cui core business è la fornitura di servizi attraverso (anche) uno dei pilastri fondato su software proprietario (ovvero Ubuntu One server-side), non può permettersi di dire certe cose senza far seguire alle parole un gesto concreto.

Mi aspetto la release del server di Ubuntu One sotto GPL molto presto.

Photo courtesy of Esther Dyson

Poscritto

Riccardo Padovani, che mi osserva silente ma quando faccio un errore mi bastona subito (e fa bene!), mi fa notare che quello che ho scritto sugli Ubuntu Phone è senza fonte. È vero. Tuttavia, dato che sinora il mercato degli smartphone non ha trattato la questione open driver in maniera “frontale”, ho sfornato quella che a tutti gli effetti è una congettura basandomi sul fatto che i primi dispositivi di test per Ubuntu Touch sono stati i Nexus, che necessitano di blob proprietari nemmeno indiferenti; quindi immagino che anche i Meizu con Ubuntu, più o meno, saranno fatti della stessa pasta.

Telegram: pro e contro

- Web

Telegram

Proprio in questi giorni, uscito dalla sessione d’esame (e rivista quindi la luce del sole) ho deciso di dare una chance a Telegram, sia dal punto di vista della tecnologia pura (quindi esaminarlo abbastanza nel dettaglio lato server) che dal punto di vista dell’utilizzo quotidiano come sostituto potenziale di Whatsapp all’interno del mio flusso di comunicazioni.

Nonostante di solito io sia un tipo che sa abbastanza cosa vuole e cosa aspettarsi, pur trovandolo sostanzialmente un surrogato per ora non totalmente pronto a sostituire uno strumento come Whatsapp (o altri, se ne usate – ma per me sono anche peggio, quindi lasciamo stare), ho toccato con mano alcune novità che hanno un potenziale enorme dal punto di vista della user experience, e che effettivamente me lo hanno fatto apprezzare parecchio, soprattutto dal punto di vista (diciamo pure) lavorativo.

Di seguito quindi, tre motivi identificati da me per cui Telegram non è attualmente una soluzione alle criticità di cui soffre Whatsapp, ma non solo: anche tre ragioni per farvelo stare, ugualmente, molto simpatico come secondo classificato.

Reinventare la ruota non è bello

Viviamo in un ecosistema fatto di tecnologie aperte, oltre che di imprenditori che sanno vendere la propria creatura a un colosso per svariati miliardi di dollari (di cui un bel po’ in stock option); per questo motivo, risulta antipatico creare un proprio protocollo che non sia basato su XMPP per la comunicazione e RSA/OTR per la crittografia, dato che sono tecnologie da sempre presenti nella storia dell’informatica, e sostanzialmente rock-solid dal punto di vista della sicurezza.

Telegram invece si basa su un protocollo proprio, che per quanto ben descritto in molteplici paper e sulla pagina ufficiale (nonché messo in pratica attraverso il codice dei client che possiamo esaminare), è comunque una cosa nuova da studiare da capo, completamente. Mtproto è molto carino come concezione, ma il team avrebbe potuto risparmiare parecchio tempo non creando tutto questo, e partendo invece da quelli che sono dei golden standard. In questo modo invece abbiamo una creatura che per quanto carina, all’interno dei protocolli di comunicazione è in ogni caso un nuovo player che ha da mostrare tutte le sue carte, e da giocarle anche con cura.

È sicuro, ma non troppo

Telegram è più sicuro. Ok, abbiamo capito. Ma questo atteggiamento irritante degli sviluppatori di Mtproto, e di chi consiglia Telegram a sua volta, si scontra con un altro atteggiamento abbastanza deplorevole, e cioè quello di chi, nel frattempo, ne ha scoperto delle gravi falle a livello di protocollo crittografico.

Geoffroy Couprie, sviluppatore per VLC e consulente per la sicurezza informatica, ha scritto l’interessantissimo Telegram, AKA “Stand back, we have Math PhDs!”, dove ha messo alla berlina un po’ di corbellerie insite all’interno di Mtproto (ossia il protocollo usato da Telegram), come ad esempio una falla abbastanza grave nella chat criptata end-to-end, in quanto lo scambio di chiavi Diffie-Hellman viene coadiuvato dal server con un’operazione per cui (facendola breve) ci si espone ad un attacco Man In The Middle – il che significa sostanzialmente che se sono abbastanza furbo da fingermi un tuo server, riesco non solo a intercettare i tuoi messaggi, ma a decriptarli senza problemi.

Vogliamo continuare? Nah, piuttosto, leggetevi anche il thread di commenti sottostante in cui gli sviluppatori di Telegram accusano Couprie di aver scritto inesattezze – cosa in parte vera e rettificata nell’articolo, ma non totalmente: altri dettagli (come quello sovrastante) sono ancora in attesa di una smentita.

Si ma… mia nonna lo usa?

Siamo in tanti ad aver installato Telegram; parecchie persone che lo usano ne incoraggiano l’adozione tra quelli che conosco, e parecchi scettici sempre nella mia cerchia gli hanno dato una chance, alcuni con successo, altri meno. Nonostante questo, però, la curva d’adozione è sempre piuttosto bassa, dato che i numeri di Whatsapp sono stati raggiunti non con un’esplosione singola, ma con una serie di boom progressivi che gli hanno permesso di diventare praticamente la piattaforma leader nel settore del messaging nel mondo.

Certo, le recenti adozioni di massa di Telegram possono avere un piccolo peso per Whatsapp, ma chi ha grosse cerchie di amici ancora fortemente legate al messenger (ormai) di Facebook non sarà così facile da smuovere: le masse si muovono solo con numeri ingenti, e sinora il punto di adozione ingente sembra per Telegram un’oasi alla fine di un lunghissimo tracciato da percorrere in un deserto costellato di ostacoli, tra cui Line con la sua interfaccia bellina, e WeChat che in Cina fa numeri da paura.

Chiaramente quindi, chi non è interessato alla nicchia (a meno che tutti i propri amici non abbiano già fatto il salto) lascerà Telegram al palo.

È open source (almeno, in parte)

Almeno, un pezzo di Telegram è open source. Ed è pure una parte consistente: anche se il server è ancora proprietario per motivi piuttosto loschi (e probabilmente i russi si stanno babbando tutti i nostri numeri di telefono per poi farci chiamare uno ad uno dai Testimoni di Putin), il protocollo è aperto, sviscerabile, e completamente comprensibile, tant’è che infatti le falle di sicurezza presenti sono state rese evidenti da svariati ricercatori che si sono interessati al tema in maniera immediata.

Stessa cosa dicasi con le API, che, ben documentate e altrettanto ben sviluppate, hanno permesso non solo la creazione di un buon client che, reso open source, può essere utilizzato anche a livello accademico per la comprensione di come un’applicazione comunica con il proprio server (in maniera cifrata, oltre tutto), e può chiaramente essere migliorato da una comunità piuttosto attiva. Se infatti l’applicazione per iOS è stata creata dallo stesso team di sviluppo, già il client Android segue dinamiche diverse, dato che la prima versione (immagino come le successive) è stata frutto di un contest, vinto da due programmatori proprio con il client che noi utilizziamo sul sistema operativo di Google.

La open API ha fornito anche l’appiglio per la proliferazione di client per altre piattaforme, approccio che non si ferma solo al mobile: abbiamo infatti anche un client per la riga di comando (compatibile con Linux e OS X), ma anche Telegram per Mac e Telegram per Windows. In mancanza di sforzi “ufficiali”, oltre tutto, anche Windows Phone ha beneficiato di una API con un tale grado di apertura (ormai obbligatorio per questioni di engagement, secondo me), dato che la community anche in quel caso ha colmato la lacuna con dei client completamente “homemade”.

Dobbiamo aspettarci un server open source di Telegram ben presto. Nonostante di solito io creda poco a queste affermazioni, forse in questo caso l’inizio è talmente buono che il progetto si merita un po’ di fiducia durante un periodo di staging proprietario che giocoforza è causato da questioni di fruibilità del codice. E quello che possiamo attendere come passo successivo, è che i client di Telegram/MTproto ci permettano effettivamente di specificare se connetterci a un server ufficiale, o ad un server che abbiamo messo in piedi noi stessi. Perché no? In fondo un servizio decentralizzato di messaggistica mobile sarebbe veramente innovativo.

Altro che balle varie correlate.

Meglio di niente

Whatsapp, si sa, è veramente pessimo sia come implementazione (un XMPP modificato in maniera abbastanza promiscua), che come sicurezza. Se infatti è vero che sono state segnalate delle falle ben chiare che mettono in pericolo la nostra privacy in maniera ingente, è anche vero che oltre questo i developer non hanno fatto gran che per proteggerci da occhi indiscreti, anzi: continuando a fatturare la compagnia si è completamente disinteressata di tutte quelle istigazioni ad attacchi man-in-the-middle, e probabilmente con Facebook al timone il comportamento sarà grossomodo lo stesso.

Telegram, invece, si trova un passo avanti da questo punto di vista: con un protocollo aperto mette in evidenza una sicurezza parecchio maggiore, oltretutto nonostante la presenza di problemi abbastanza rilevanti nell’algoritmo di crittografia, dovuti per lo più alla possibilità di attacchi MITM (anche in questo caso), l’atteggiamento degli sviluppatori sembra costruttivo e – tanto per tornare al punto di cui sopra – l’apertura dimostrata non tanto in fase di progettazione quanto di condivisione del lavoro svolto fa ben sperare, e sicuramente fa da grimaldello per chi cerca un’azienda fornitrice di servizi che ha a cuore in maniera maggiore la sicurezza di uno scambio di informazioni.

È una tecnologia migliore

Quella introdotta da Telegram è inevitabilmente una tecnologia migliore, perché si sposa meglio con i bisogni dettati da un mercato che è stato completamente rivoluzionato, nel bene e nel male, da una certa attenzione per l’aspetto della sicurezza. Anche se non ancora completamente aperta, sulla carta la tecnologia utilizzata da Telegram è decisamente migliore di quella alla quale ci dà accesso Whatsapp. Una persona un po’ attenta a questo tipo di caratteristiche per cui dovrebbe sicuramente considerare uno switch, a meno di non prendere in considerazione anche altri fattori di cui sopra.

Non credo ci sia molto da dire. Uso Telegram da un paio di settimane, affiancato a Whatsapp come messenger principale sul mio smartphone Android e sulle mie macchine. Certamente c’è da lavorarci su. Tuttavia, l’approccio al servizio mi pare interessante, per quanto approssimativo come business plan (chi paga? Pantalone?); c’è solo da aspettare, sicuramente il team si merita un po’ di supporto e parecchi feedback.

Open source: come cambiano i business model

- Open Source

Open Source

The biggest driving factor for software developers to work together with open source is cost. It is much cheaper for them to cooperate through open source than it is to remain isolated with proprietary software, asserted Inktank VP of Product Management Neil Levine. “You can no longer rely on one particular vendor to provide everything you need with regard to technology.”

Un piccolo estratto da un articolo veramente interessante che ho letto oggi, sull’open source e la coopetition, dove viene mostrato come grazie ai nuovi business model portati avanti all’interno di un ecosistema simile i modelli comportamentali adottati dalle strutture di governance e gestione dei progetti divengano man mano più sagge, calibrate, e chiaramente collaborative (e come questo porti ad ammortizzare i costi colmando i debiti tecnici).

Consigliatissimo; specie il paragrafo “Opposing becomes joining”.

Photo courtesy of opensource.com

Twitter Bootstrap, l’interfaccia grafica del web

- Web

code

Oggi ho letto questo interessantissimo post di Dave Winer che espone un notevolissimo punto di vista per quello che riguarda Bootstrap, il framework per frontend development/design distribuito tramite GitHub (open source) da Twitter.

The idea of Bootstrap, as I see it, is to add a layer of standardization between the app developer and the “hardware,” in this case, the user interface offered by the modern HTML 5 web browser. When you view it this way, there’s nothing controversial about it. It’s what engineers always do. When we see complicated chaos, we try to figure out what’s really going on, and produce a simplified and rational view of it. Then all the code that rides on top of the new layer can also be rational and relatively simple.

Sostanzialmente Winer espone una tesi: con Bootstrap si sono venute a creare delle inconsapevoli HIG (Human Interface Guidelines), dato che l’utente riconosce un’applicazione creata con questo toolkit e ne identifica un certo design pattern che lo porta a cercare i menù e gli elementi familiari sempre negli stessi posti, un po’ come funziona per le interfacce grafiche dei computer.

Questo viene stimolato in un certo senso dalla replicazione degli stessi elementi grafici (ad esempio l’aspetto dei bottoni) tra un sito e un altro. In poche parole, Bootstrap è diventato il GTK, il Cocoa del web: un toolkit con cui costruire interfacce, il più popolare, e probabilmente ciò che ha iniziato a definire un livello successivo (come dice anche il post originale) di come è possibile continuare la catena del software nel web.

Photo courtesy of Michael Imbeault

Red Hat / Fedora: RPMDB altered outside of yum

- Linux

Fedora htop

Di recente sulla mia workstation con Fedora ho cominciato a pastrugnare con il package management in maniera indiscriminata, così invece di far fare tutto a Yum che mi dava qualche piccola incongruenza, per installare un pacchetto mi sono avvalso di RPM puro, cosa che ormai a quanto vedo non dovrebbe essere mai fatta, demandando a yum localinstall il compito di installare pacchetti singoli.

Fatto sta, che ho avuto un feedback “strano” dalla mia macchina provando a usare direttamente RPM: ha cominciato a rompermi le scatole ad ogni operazione di gestione dei pacchetti avvisandomi che il database di RPM era stato modificato senza che Yum lo avesse autorizzato.

Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.

Al di là di ogni presa di coscienza del fatto, e procurato allarme (ok, ho scardinato RPM, ho capito), può essere utile rimettere in marcia il nostro sistema senza che mostri più quel feedback che, con tutto il rispetto, ma mi ha fatto prendere un accidente. Mi sono guardato un po’ intorno e ho notato che basta dare un singolo comando per liberarsi di questo peso sulla coscienza:

$ sudo yum clean all

Occultamento di cadavere? Forse si. Ma se la macchina la amministriamo noi, chi se ne importa. Buon lavoro :-)

Photo courtesy of Kaleb Fulgham

Registry npm privato: in cloud con Nodejitsu oppure in-house

- Open Source

Node.js

Proprio in questi giorni, ho letto che Nodejitsu ha cominciato a implementare il proprio modello per i registry privati di pacchetti npm in modo che le aziende possano mantenere i propri package privati su un server in cloud a prezzi comunque sostenibili. Il tutto si basa sull’utilizzo del modulo di Node smart-private-npm; di seguito, un esempio preso dal loro blog dove sfruttano Node.js per fornire un registry privato insieme alla loro libreria, da poco (immagino) resa open source per chi comunque non può permettersi un costo così elevato (perché in startup o per qualche altro motivo) e decide di sostituire al costo della cloud qualche ora di effort e una macchina – o una VPS. Ovviamente io consiglio DigitalOcean che permette l’hosting di droplet su SSD :D

var smartPrivateNpm = require("smart-private-npm"),
    url = require("url");

//
// Configure your private npm. You could load this in from a file
// somewhere.
//
var config = {
  rewrites: require("./config/rewrites"),
  proxy: {
    //
    // Location of the target public npm registry. 
    //
    npm: url.parse("http://user:pass@registry.nodejitsu.com"),
    //
    // Private npm options.
    //
    policy: {
      npm: url.parse("http://user:pass@private.registry.nodejitsu.com"),
      private: {
        //
        // This is the list of 'known private modules'
        // that will always be proxied to the private npm.
        // It is built over time by remembering 'publish' requests.
        //
      },
      blacklist: {
        //
        // This is the list of modules that will ALWAYS be proxies
        // to the private npm, no matter what.
        //
      },
      whitelist: {
        //
        // If enabled: only requests for these modules will be served
        // by the proxy (unless they are 'known private modules').
        //
      },
      //
      // In 'transparent mode' the proxy will always forward to
      // the public registry.
      //
      transparent: false
    }
  },
  //
  // Server options (from 'create-servers')
  //
  http: 80
  https: {
    port: 443,
    root: "/path/to/your/ssl/files",
    key: "your-ssl.key",  // or .pem
    key: "your-ssl.cert", // or .pem
  }
};

smartPrivateNpm.createServer(config, function (err, servers) {
  if (err) {
    console.log("Error starting private npm: %j", servers);
    return process.exit(1);
  }

  console.log("Private npm running on %j servers.", Object.keys(servers));
});

Per l’operazione di pubblicazione dei pacchetti npm su un registry diverso, va semplicemente riadattato poi il comando che andiamo a dare nella shell:

npm publish some-private-code --reg http://localhost/

Ho trovato con cosa giocare stasera dopo il lavoro. In bocca al lupo a chiunque si voglia cimentare, e come sempre grazie a Nodejitsu per tutto l’open source che ci regala.

Photo courtesy of Trygve Lie

Flow: il mio nuovo tema per WordPress è open source

- Open Source

github open source

In due o tre, dall’ultimo restyle del blog che risale a questo capodanno, mi hanno fatto i complimenti per il nuovo tema; effettivamente non c’è voluto molto, ma ho dovuto mettere insieme qualche tassello per permettere la modifica della foto nell’header e qualche altra cosetta. È anche la mia prima esperienza diretta con il responsive web design: finora avevo demandato tutto a framework come Foundation o Bootstrap, ma ho deciso di fare tutto da zero e scrivermi un po’ di media query da solo (con stili associati).

Flow (ho deciso di chiamarlo così) è su GitHub sotto licenza GPL2 per motivi di fork dal tema padre, Lean, a sua volta basato su Underscores; mi sono trovato molto bene a costruire un tema su Underscores, tuttavia anche le opzioni che ha elencato Francesco recentemente non sono niente male, e se dovessi ripartire da zero oggi userei BlankSlate.

Cosa c’è e cosa non c’è

  • Per il momento all’interno del tema è presente la possibilità (implementata nel functions.php con delle specifiche precise) di cambiare l’immagine dell’header, che in questo caso è banalmente la foto circolare. In questo blog c’è la mia, ma di default ho inserito un simpatico capibara.
  • Il codice è quello che è, è mio e ogni scarafone è bello a mamma sua. Ogni lamentela che non alleghi una pull request non verrà presa in considerazione. :D
  • L’aspetto meno simpatico è che ho fatto hardcoding su un paio di cosette come il mio nome e il “gdb ./life” presente nella testata. Al momento non ho in programma di portare questi aspetti ad un livello più pulito e di backend, quindi chi vuole usare il tema lo modifichi tranquillamente. Chi invece ha tempo e voglia di perderci una mezz’ora a implementare un pannellino di configurazione, ha una birra pagata quando ci vediamo.
  • Flow è responsive!
  • Alla batteria, Mike Mangini.

Che altro dire: divertitevi. :)

Photo courtesy of Brennan Bearness

Il mio regno per il 4K

- Tech

4k monitor

The toleration of mediocrity on the desktop irks me.

Così recita Brian Hauer in un suo recente post che ha fatto parlare un bel po’ sviluppatori, hacker e nerd in generale, e devo dire che mi sento abbastanza d’accordo. Partiamo con un po’ di background, che fa sempre bene: qualche mese fa ho fatto un nuovo acquisto, ossia un All In One con monitor da 27 pollici e specifiche tecniche parecchio elevato, marchio ASUS, totalmente compatibile con Linux, e tremendo gaudio sia lavorativo che per quanto riguarda l’entertainment. Ci ho infatti sostituito persino il televisore, ormai rimasto alla mia famiglia meno digitalizzata (anche se, aehm, mia madre ne ha preso uno con ingresso USB poco dopo: devo aver inoculato il germe dell’USB anche in casa).

Bello eh, anzi: riesco a tenere aperte parecchie cose contemporaneamente, ma sento ancora la necessità di un secondo monitor, e – per quanto io stia provando a far entrare nel mio “studio” una scrivania più grande – le dimensioni sono quelle che sono, la metratura pure, e quindi per ora me la devo amabilmente prendere in quel posto; diversamente, con un solo monitor, sostenuto da una sola base, anche più grande, riuscirei comunque ad avere un diverso assetto con la scrivania che ho, mantenendo l’arredamento simile e avendo più spazio “digitale” (desktop! LOL) a disposizione.

Se debbo fare un appunto alla mia workstation infatti, è solo la densità di pixel “standard”. Questo (vista l’avanguardia generale della componentistica di cui parliamo), esattamente come per Hauer, genera in me un certo disappunto. Parecchio disappunto.

Questo mi serve, altro che 3D

Vabbeh, vedémoselo.

Più o meno questa è la reazione mia e dei miei amici, ogni volta che andiamo al cinema (chiaramente a Roma come avete percepito dall’accento) e ci viene proposto un film in 3D dove non è possibile scegliere l’alternativa in 2D. Chiaramente non è che io sia contro il 3D, che anzi al cinema è un’esperienza carina, ma tra lo spam dei cinematografi e la campagna d’assedio a cui ci ha sottoposto chi vende monitor e televisori, ne ho avuto veramente abbastanza di chi ha voluto veramente farci credere che la risoluzione non fosse più un fattore importante e discriminante nella scelta di un dispositivo di visualizzazione.

Così, quando per la prima volta ho visto un monitor 4K, e a maggior ragione quando ho letto il post in oggetto, ho pensato una sola cosa: “Avete finito di cercare di infinocchiarci, maledetti”. Semplicemente perché mentre della tecnologia di riproduzione 3D possiamo fare a meno in quanto inerente prettamente l’ambito della divertenza (che termine fico eh), l’ambito della definizione e della risoluzione è qualcosa dove, al confronto con un monitor – o meglio ancora un televisore – 4K, un dispositivo tradizionale mostra il fianco, e senza cotta di maglia.

Con lo spazio per 4 colonne di editor di testo aperte, svariati terminali con qualcosa in esecuzione dentro, e la possibilità di affiancare a tutto comunque un browser per visualizzare il risultato del nostro sviluppo web, o l’emulatore dell’SDK per chi sviluppa nel settore mobile (e così via…), le specifiche di qualsiasi cosa che non sia l’ultimo modello di Zenbook dove su un 13 pollici abbiamo una risoluzione di duemilacinquecento e rotti pixel in orizzontale, risultano tremendamente imbarazzanti. Ma che dico imbarazzanti, praticamente di un’era passata.

Risoluzione, definizione, monitor e fattori di forma (un sacco di roba quindi)

Da quel che so, il sesso non ha avuto aggiornamenti con grafica ad alta definizione e armamenti potenziati. – Sheldon Cooper

Dato che un televisore 4K al posto di un monitor mette in luce quanto l’industria degli schermi si sia adagiata sugli allori, e questo l’abbiamo già acclarato abbondantemente, azzardiamo anche qualche previsione su quello che succederà in questi anni di profonda rivoluzione nel campo desktop, a causa di qualcosa che finalmente serve alla massa e non ai proprietari dei cinema per venderti un biglietto da 10 (dieci) euro – o se preferite, a chi vuole venderti un 40 pollici che, al posto di fare il televisore, potrà fare tranquillamente da soprammobile. Con buona pace degli amanti del treddì.

  • Il porno: Naughty America ha annunciato proprio in questi giorni che sono i fase pianificazione i primi film pornografici girati in 4K. Modestamente, in quanto esperto dell’ambito (:D), ritengo che questo cambierà parecchi aspetti nell’ambito home video: dato che il VHS ha vinto contro il Betamax complice il porno, la spinta dell’industria pornografica se ingente ha le carte in regola per rendere 4K un successo, mentre il “good enough” 3D nell’ambito rimarrà al palo. E si sa, per chi rimane al palo nel mondo del porno butta male. Oddio, effettivamente dipende da quale palo.
  • L’imbarazzo dell’anzianità: qualche tempo fa ho avuto l’immenso piacere di provare il Dell XPS Developer Edition, che un mio coworker ha anche acquistato. Il lavoro su uno schermo a così alta risoluzione è comodissimo, e immagino che lavorare con un monitor 4K mi farebbe voglia di fiondare dalla finestra il mio All In One esattamente come dopo aver provato l’XPS  è stato terribilmente traumatizzante tornare al mio “legacy laptop” con il suo monitor, per così dire, stretto.
  • Le dimensioni contano: mettiamo caso che finalmente arrivi un monitor 4K ad un costo decente, come ipotizza anche Hauer; a questo punto, con abbastanza spazio per quattro colonne di editor di testo, svariate CLI aperte e uno o più browser, tornereste veramente ad una configurazione della scrivania con monitor multipli? Nonostante a me piaccia la configurazione multi-monitor e io sia dell’opinione che i pixel non sono mai troppi, i limiti fisici della mia scrivania mi impediscono sia di avere due monitor, al momento (ed è per questo che sto cambiando scrivania eh), ma anche se questa fosse più grande preferirei risparmiare spazio in favore di qualcos’altro. Insomma, in due parole: le nostre scrivanie, dopo l’avvento e la massificazione del 4K, non saranno più le stesse.

Quando vi tireranno fuori l’ennesimo pacco per farci accontentare della qualità d’immagine attuale, non date soddisfazione a nessuno. D’altronde, il regno del 4K sta per cominciare, ma l’8K si profila già all’orizzonte, e potrebbe darci ancora più soddisfazione.

Photo courtesy of Tutaka Tsutano