30 Mar 2013
Come sapete, da qualche tempo sto usando Fedora (al momento Fedora 18) con GNOME e devo dire che mi trovo, se non molto bene, di sicuro "non male": ovviamente c'è il supporto hardware solito tipico di Linux, e GNOME Shell ha fatto un po' di passi che se non sono da gigante comunque lasciano intravedere la speranza per chi, con le prime release, ha storto il naso (sottoscritto compreso). La mancanza più grande che ho riscontrato sinora però è quella di gMTP.
Per chi non sapesse cos'è MTP, copincollo da Wikipedia:
L' MTP (Media Transfer Protocol) è un set di estensioni del PTP (Picture Transfer Protocol) creato da Microsoft, per consentire l'uso di lettori MP3, macchine fotografiche digitali e altri dispositivi digitali portatili. MTP è fortemente legato a Windows Media Player. L'utilizzo di MTP al posto del classico MSC (mass storage class) comporta alcuni vantaggi pratici per gli utenti che utilizzano abitualmente Windows Media Player, ma rende di fatto meno accessibile la periferica rispetto ad un utilizzo col protocollo MSC. Ad esempio: un lettore MP3 che viene visto tramite MSC come una comune chiave di memoria (e quindi anche in Risorse del Computer si comporta come tale) è molto più versatile di un lettore MP3 che utilizza il protocollo MTP e che viene visto dalla gestione delle risorse del computer come dispositivo "Hierarchical", cioè come sotto cartella di risorse del computer. Le sottocartelle poi non portano indicazione sulla data e l'ora di creazione dei file contenuti (molto scomodo se il lettore MP3 è dotato di registratore vocale in quanto si perdono la data e l'ora in cui sono stati registrati i dati; infatti una volta trasferiti sul pc acquisteranno la data e l'ora del momento esatto del trasferimento. Altro difetto sta nel fatto che durante un trasferimento non si deve chiudere la cartella del lettore mp3 dalla quale si stanno prelevando i file altrimenti il trasferimento si interrompe.
Ora, piccolo approfondimento, che molti conosceranno già: in cerca di un protocollo migliore per gestire i trasferimenti di file in Android, Google ha deciso di utilizzare MTP che è probabilmente (anzi sicuramente) il protocollo "meno peggio" in circolazione riguardo il file transfer tra dispositivi. Il problema è che MTP gode del seguente supporto presso i maggiori sistemi operativi:
- Windows lo supporta ottimamente (ci credo: è il loro)
- Mac OS ha bisogno di un frescobuffo che si chiama Android File Transfer - che, per chi non lo sapesse, e si ostinasse a denigrare il software open source in ogni sua forma, è una GUI per libmtp, progetto aperto. Sucate.
- Su Linux, come sopra, abbiamo libmtp che però ha una corolla di interfacce grafiche e a riga di comando notevoli. La mia preferita è gMTP che, pur funzionando (scusate la ruralità dell'espressione) a cazzo, è anche in questo caso la meno peggio. Semplice, efficace, fa il suo mestiere.
Il problema è che pur essendo nei repository di tutte le distro del mondo, come al solito Fedora, sguarnita più di un supermercato il giorno dopo Natale, non ce l'ha. Mi sono quindi ingegnato e editando uno spec che ho preso da Fedora Forum, ho creato il mio bel pacchetto sorgente con l'ultima versione di gMTP, pronto per compilare su qualsiasi Fedora 18 di questo mondo. Dovrete armarvi di un po' di buon senso, la linea di comando e delle vostre incantevoli dita, dopodiché, come ci dice anche il wiki di CentOS:
wget http://dl.dropbox.com/u/685412/f-pkg/gmtp-1.3.4-2.fc18.src.rpm
rpm -i gmtp-1.3.4-2.fc18.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -ba gmtp.spec
Dando questi quattro comandi riusciremo a produrre un RPM di gMTP perfettamente funzionante, che possiamo installare come vogliamo; io ho usato rpm da CLI perché il frontend era andato in sciopero per ragioni a me ignote.
Note nerd
Oh, figo rpmbuild!
Non avevo mai visto una cosa così caruccetta nei modi e nelle configurazioni. L'unica cosa che gli assomiglia per la mia esperienza è ABS, il sistema di port di Arch Linux, ma la sintassi degli spec per costruire un RPM è decisamente poco complessa, con header ben definiti e contenuti stra-leggibili. Sembra - azzardo - quasi un file markdown più che qualcosa dove vengono istanziate delle variabili. Ne sono rimasto piacevolmente sorpreso, adesso come in altre occasioni. Sicuramente, sia rpmbuild che makepkg sono anni avanti a quello che è (mi scusino i debianisti) il modo di creare un pacchetto DEB, pacchetti per i quali ho buttato il sangue a suo tempo e sui quali ho promesso di non ripetere più l'esperienza traumatica.
Photo courtesy of Fernando Weno
29 Mar 2013
Visto che la storia si ripete, come diceva il buon Giambattista Vico, ma anche Nietzsche, ma anche insomma un po' tutti e a partire da Vico questa citazione è stata ficcata un po' in bocca a chiunque, nell'ambiente dell'open source si vengono spesso a creare fork di fork di fork semplicemente perché a qualcuno non sta bene un pelo nell'uovo, rifilando poi alla potenziale userbase delle promesse che nemmeno $politico_a_scelta.
Quindi, esemplifichiamo, perché la vita è più bella con gli esempi:
- Un cane manda una patch scritta male per girare a suo piacimento l'andamento di un progetto open
- Tale patch gli viene rifiutata (not compliant, non c'entra una mazza col documento di progetto, o altro. Metteteci quello che vi pare come ragione)
- Il suddetto cane piange
- Il suddetto canide alza una canizza (come appropriato) in mailing list di progetto o sul bugzilla, facendosi aiutare da qualche developer più cane di lui
- La discussione prosegue con toni supponenti da parte del "developer", con pazienza il team gli propone di migliorare la patch e provare a sottoporla durante la prossima merge window
- "Procrastinatori! Nazisti! Il team di sviluppo non ci ascolta, non è abbastanza open" (ignorando l'esistenza di specifiche e documenti di progetto). Il cane forka il repository (aka codebase)
- Il cane promette sul suo blog (che passa da 20 visite al giorno - di bot come Google - a 4000 visite giornaliere) meraviglie, lo zip uor airghenon et similia
- Su una codebase di 400 mila righe di codice il cane riesce a fare il rename di qualche software. Il resto no. Ma mica per altro, è che semplicemente non capisce quello che legge.
- Imprecazioni sul blog contro parti di codice non commentate, mantenute regolarmente nell'altro progetto che altrettanto regolarmente prosegue il suo ciclo di vita
- La gente (utenti, ndr) comincia a scocciarsi
- Dopo due anni di lavoro viene rilasciata una specie di golden master (alpha, beta, 'n se capisce bene) indietrissimo rispetto al progetto originale
- Il team di sviluppo (già poco numeroso) si defila
Credo di aver terminato. In caso posso aggiungere altri passi, basta dirmene nei commenti.
Photo courtesy of Diego Sevilla Ruiz
28 Mar 2013
Ci sono diverse ragioni (e tra le piú disparate) per il titolo di questo post:
- Mi fa SEO, che non è mai una brutta cosa;
- È un bel claim (vedasi la ragione di sopra);
- È una cosa che mi interessa in prima, seconda, e terza persona - singolare e plurale;
- Ma soprattutto Ben Werdmuller ha scritto questo interessante, meritevole, notevole (inserite altri aggettivi positivi qui) post dove spiega alcuni concetti abbastanza semplici.
A prescindere dai business model elencati infatti abbastanza attivo nel movimento open source e arrivato a capire in qualche anno che sulla sua testa pende una sorta di condanna: il contraccolpo dell'effetto buzzword infatti lo ha reso un tema al limite dell'impopolare, e chi si sforza di costruire conversazioni tra team non me beneficia affatto.
Vi consiglio la lettura del post di cui sopra; nel frattempo, alcune riflessioni al volo su quanto ci si può leggere dentro. Prima cosa, mettere in luce i casi di studio. I nostri clienti o i nostri amici (banalmente) possono essere spaventati dalla fine che hanno fatto progetti come StatusNet e Diaspora. Sta a noi portare in gioco compagnie come Red Hat e software come WordPress, che sicuramente ormai sono diventati dei veri e propri motori dell'economia, in totale apertura, e in totale assenza di paura del feedback comunitario. Seconda cosa, identificare le nostre best practice di riferimento. Ci sono un sacco di modelli che hanno generato profitto negli anni per progetti anche completamente aperti: facciamoli nostri, accettando di dover applicare un po' di inventiva perché magari roba trita e ritrita. Non buttiamo nemmeno i grandi fallimenti (come lo stesso Diaspora) che con qualche colpo di reni avrebbero potuto conquistare le scene.
Fine dei consigli per gli acquisti. E leggetevi il post - lo ripeto - ché è fighissimo. Torno ad ascoltare i Dream Theater. E daje che 'sta settimana ricomincia Game of Thrones.
Photo courtesy of JD Hancock
25 Mar 2013
Dato che del lavoro ne ho fin sopra i capelli per questi giorni, mollo tutto e mi dedico a raccontare un po' di cose.
In questi giorni ho curato alcune cose: lo speciale sul Codemotion di HTML.it, di cui potete leggere i post (by me) sugli interventi che mi hanno colpito di più sul nostro blog. È una di quelle cose che di solito mi diverto a fare, perché per scrivere su un company blog bisogna necessariamente cambiare registro rispetto alla scrittura tradizionale (come quella che vedete qua).
Non solo: per Leo Hi-Tech ho cominciato a pubblicare i resoconti degli speech che mi hanno stuzzicato per così dire "lato maker" o comunque tecnologicamente parlando. Aspettatevi quindi un resoconto anche sulle stampanti 3D di Kentstrapper, e qualcosa sul robot che risolve Ruzzle (di cui posterò pure il video nei prossimi giorni).
La cosa notevole, post a parte, di questo Codemotion, è stata la visione dell'open source che è stata data da diversi speaker: qualcosa di necessario, e che parecchie volte funge da catalizzatore per un'idea che ha solo bisogno di un'integrazione di alcuni componenti con una "limata" finale. Ho partecipato, a tale proposito, anche alla tavola rotonda di Andrea Mignini (ILDN) sullo stato dell'open source e in particolare di Linux in Italia, occasione che ci ha permesso (me e gli altri presenti) di mettere a fuoco alcune problematiche come la chiusura stagna di alcune community, e di analizzare anche possibili soluzioni.
A parte tutto quello che consegue dal lavoro, tuttavia, le cose belle me le hanno regalate gli amici. Lorenzo Cantini (Kentstrapper, di cui sopra), su richiesta si è fatto scippare un meraviglioso fischietto rigorosamente stampato in 3D. Luca Bonesini mi ha regalato uno dei momenti migliori di networking di tutta la mia (breve?) vita, nonché un bel po' di risate al corner di Sourcesense, messo proprio di fianco a quello di nois3lab, per celebrare la nascita di RIOS (Rete Italiana Open Source). Oltre questo, una menzione d'onore va ad Alfredo, di Google, per aver reso possibile un sogno: oggi sulla mia scrivania c'è un peluche di Android che si fa fare le coccole, e devo ringraziare lui.
Non finisce qui: Lorenzo è stato il mio compagno instancabile lungo un sacco di interventi e ha sopportato anche il fatto che prendessi appunti invece di parlare con lui, supportandomi nel mio lavoro di cui sopra. Ultimo, ma non per importanza, Alessio (darthpelo, omonimo - e se qualcuno dei due avesse scelto, sarei sicuramente io ad avere lo stesso suo nome): l'evento è iniziato infatti come una gita delle medie con lui come compare di autobus, e le sue frecciate nerd mi hanno accompagnato lungo tutta la prima giornata. Peccato non aver poi proseguito la chiacchierata davanti ad un hamburger.
Un caloroso grazie anche a tutti gli speaker che ho seguito, tutti davvero preparati e con una presenza scenica media notevole.
Photo courtesy of Alessio Jacona
18 Mar 2013
Conoscete BitNami? No? Descriverla è semplice: si tratta di una compagnia che gestisce una sorta di repository di script di installazione o deploy per soluzioni comuni e stack di software open source come WordPress, tra i più semplici, o Magento, tanto per nominare qualcosa di un po' più esotico. Conoscete GitLab? No? È un software che ho anche nominato più volte nelle mie imprecazioni, che essenzialmente si pone come un'alternativa open source a GitHub per il management dei repository (git) di codice, grafico, via web.
Nonostante sulla carta GitLab sia un software validissimo sulla carta, soprattutto adesso che ha annunciato il voler rendersi indipendente da Gitolite nella prossima versione, l'installazione di questa sorta di CMS del repo management rimane per me un mistero, indipendentemente dalla sua ottima documentazione su Arch Wiki. Sono quindi contentissimo del fatto che BitNami offra da pochi giorni l'installazione in pochi click dello stack di GitLab, in modo assolutamente indolore.
La potenza dell'open source: qualcun altro può porre rimedio alle procedure più fastidiose conoscendo bene il funzionamento del software. In questo caso BitNami ha automatizzato il punto negativo probabilmente più imponente per GitLab, quindi io ovviamente sono contentissimo. E, cari sistemisti, cari smanettoni, cari nerd casalinghi, dovreste esserlo anche voi.
Photo courtesy of Johannes Gilger
