Syn, il package manager di Paul Tagliamonte

Stavo stiracchiandomi comodamente alla mia scrivania dopo una stancante ma produttiva e soprattutto interessante giornata universitaria, quando ho visto con la coda dell'occhio spuntare fuori un elemento più che pregevole dal mio Google Reader. Clicka che ti riclicka, da Planet Ubuntu ho pescato questo post di Paul Tagliamonte che, tra una botta di pazzia e un'altra, ha deciso di imbracciare le sue armi per costruire nientepopodimenochè un package manager.

Ebbene si, un nuovo gestore di pacchetti chiamato Syn, l'ultima creatura per ora solo in forma di mockup del buon Paul, che da una parte mi sorprende per la volontà di creare un progetto del genere nel 2011, quando di package manager dovrebbero essercene già abbastanza, dall'altra mi solletica. Già, perchè seppur nella sua inconcretezza, questa piccola follia narrata sul blog di Paul episodio dopo episodio sarà sicuramente trasformata, in futuro, in una serie di articoli estremamente didattici; una di quelle cose in stile "cosa fare - cosa non fare", più vari episodi simbolici.

Insomma, oltre le solite considerazioni, banali, di rito, posso sentirmi di dire: vai Paul, vai così. E tutti a leggerci l'inizio della storia.

HTC Desire: S-OFF, di che si tratta

È la prima volta che faccio un post relativo ad un solo terminale, ma bisogna anche capire la circostanza: odio riferirmi ad una sola branca dell'utenza di un sistema operativo, e così come quando parlo di Linux cerco di essere il più possibile "distro-agnostic", anche quando parlo di Android (che alla fine è sempre Linux) cerco di prescindere dal tipo di terminale che maneggio.

Tuttavia, la circostanza richiede un post apposito, sia perchè molte case non bloccano sino a questo punto il bootloader dei loro dispositivi, sia perchè alcune delle procedure descritte sono valide per il solo Desire. Ma iniziamo, parliamo di S-OFF.

Cos'è S-OFF?

S-ON, il contrario di S-OFF, è un modo molto carino per ricordare a te, povero utente sfigato, che polvere sei e polvere ritornerai. In poche parole, S-ON è la sigla che corrisponde ad un bootloader dotato di misure di sicurezza tali da impedire l'installazione di immagini (recovery, system e quant'altro) non firmate. Quindi, in parole povere, niente smanettamenti paurosi tramite fastboot, e niente mount in scrittura di /system, /cache, e così via. Il motivo per cui tutto ciò è importante, è che tramite la possiblità di scrittura in /system si aprono un sacco di possibilità a livello di hacking, permettendo la manipolazione del filesystem di Android e di ogni file del proprio dispositivo, senza limitazioni.

S-OFF è la sigla che corrisponde ad un bootloader sbloccato, che permette di fare tutto ciò. Per ora AlphaRev, un hacker della comunità XDA, ha rilasciato il proprio tool per la procedura di S-OFF funzionante con HTC Desire, Legend ed Espresso; il processo è piuttosto semplice, e basta fare riferimento a questa pagina che, seppur nella sua mediocrità estetica, risulta piuttosto utile a livello di contenuti.

Effettuare la procedura di S-OFF

S-OFF può essere facilmente raggiunto scaricando l'immagine ISO del toolkit, e masterizzandolo su un CD. Io per comodità ho creato una pendrive USB da cui fare il boot, anche perchè reputo il CD-ROM un mezzo piuttosto antiquato, e dire che ho dovuto usarlo per presentare il mio progetto di Ingegneria degli Algoritmi. Dicevamo, la ISO: masterizziamola, copiamola, scriviamola da qualche parte e bootiamola: ci ritroveremo in un ambiente basato su CrunchBang Linux, nel quale girerà subito in automatico lo script di AlphaRev: ci basterà collegare il nostro dispositivo con il debug USB abilitato, e in qualche minuto (più un paio di reboot) avremo il nostro dispositivo completamente sbloccato.

Come accorgersene? Facile: riavviando in Bootloader Mode, vedremo la scrittina viola "Alpharev" sopra tutto, e avviando in maniera normale anzichè il solito bootscreen di HTC avremo Heat Ledger nei panni del Joker che ci saluta con la manina. Bene, a questo punto, abbiamo fatto l'S-OFF. Che fare?

Divertirsi con Fastboot e ADB

Io personalmente ho flashato subito una recovery custom. Direte "e beh, ma che differenza c'è, lo facevi anche prima" ma... non è proprio così: AmonRA 2.0.0 infatti necessita di S-OFF per poter essere flashata in maniera tradizionale, e siccome Unrevoked non ne vuol più sapere di funzionare in maniera decente sulle mie macchine, ho deciso di usare le maniere forti.

Cambiare HBOOT

Questo è meglio se non lo fate, dato che cambiare HBOOT è una procedura un po' rischiosa per il dispositivo. L'HBOOT è quell'affascinante cosa che tra una riga di codice e l'altra definisce, nella memoria interna, quanto spazio assegnare al sistema operativo e quanto ai dati dell'utente. Una sorta di tabella delle partizioni, ecco.

Capita quindi che usando ROM più piccoline di quella stock, ci si ritrovi con comunque poco spazio per i dati: si può cambiare HBOOT con un altro che abbia un'allocazione di spazio per l'OS minore, per ritrovarsi così con una memoria interna leggermente più capiente. Dato però che il reflash dell'HBOOT è una di quelle due o tre procedure che se non vanno a buon fine trasformano il telefono in un sasso molto costoso, per ora non voglio arrischiarmi. E non fatelo neanche voi. Ho scritto tutto ciò solo a titolo informativo.

Pastrugnare /system

Adesso che siete S-OFF potete giocare come vi pare e piace con il vostro sistema: cambiare bootscreen, cambiare boot animation e soprattutto modificare qualunque tipo di file residente in /system, come ad esempio qualche script che non vi piace e che volete migliorare. Magari, dopo cento e più edit, l'OS sarà più simile ad una ROM cucinata da voi che all'originale :D

In ogni caso, la procedura è semplice; c'è sempre da stare attenti mentre la si esegue dato che viene riflashato l'HBOOT con i rischi scritti su, quindi magari è meglio stare all'erta, in ogni caso è tutto abbastanza facile e indolore. Happy hacking ;)

Daniel Robbins - Costruire una distribuzione

Parlavamo poco tempo fa di come gestire un progetto open source: nei commenti si sono sviluppati pensieri interessanti, alcuni simili alle riflessioni fatte da me, altri contrari ma comunque ottimi spunti di riflessione sulla filosofia open e, soprattutto, sulla gestione del codice e dei programmatori, cosa più pragmatica.

Ripensando a questo, mi è venuta in mente una cosa: ma voi l'avete mai letto Making the Distro? Si tratta di un insieme di tre articoli, scritti dal fondatore di Gentoo Daniel Robbins, che parlano proprio di come costruire una distribuzione, partendo si dal lato tecnico, ma affrontando anche argomenti molto più "umani". Questo povero ragazzo che era Daniel all'inizio infatti, ha riscontrato costruendo giorno dopo giorno una delle migliori distro di tutti i tempi, che in realtà gestire un mucchio di gente, parlarci, cooperare, può diventare una fonte d'ira non indifferente. E soprattutto ha constatato con mano come l'open source, ai tempi come ancora adesso, non sia esattamente tutto rose e fiori.

Certo, la storia è da contestualizzare, tuttavia io penso che una letta alle righe scritte da Daniel non possa fare altro che bene, sia per vedere tecnicamente e umanamente come è nato il toolkit di Gentoo (specialmente Portage), poi per godersi un ottimo resoconto, una appassionante storia, di come un ragazzo possa creare un punto fermo nella storia dell'informatica anche solo hobbisticamente. Lo fece Linus Torvalds col kernel, lo fece Daniel Robbins con Gentoo.

Sul serio, leggetevi "Costruire una distribuzione". Vi farà bene. Ed è divertente.

Terrore e tensione

Come in molti si sono accorti, e come ho postato su Twitter la sera di Lunedì, questo blog è stato irraggiungibile per tutta la serata e la mattinata, più o meno, del giorno dopo. Il problema? Oh beh, semplicemente, improvvisamente ogni pagina di Wordpress restituiva l'errore 404 del CMS. E, scoprendo ciò, la mia esclamazione è stata puntuale:

[blackbirdpie url="http://twitter.com/#!/dottorblaster/status/29666439396855809"]

A questo punto, mi sono messo a cercare cosa ne fosse la causa, e a quanto pare l'errore era molto simile (per non dire uguale) ad un altro errore causato da non si sa bene cosa, come ho letto su questo topic: fatto sta che, dopo essermi loggato in amministrazione e aver lanciato un repair di tutto il database mySQL, comunque continuava a non apparire una beata mazza; prima di convincermi che la corruzione del database era una falsa pista, ho aspettato fino al mattino dopo, quando disperato ho chiesto aiuto, e in tanti mi hanno consigliato su dove guardare per questa faccenda.

Alla fine il problema era l'htaccess che, modificato, richiamava un file malevolo ad ogni richiesta PHP. Resomi conto dell'intrusione, ho rinforzato un po' le protezioni sul mio Wordpress e ho riportato il file allo stato originale; tutto è tornato immediatamente al suo posto.

Morale della favola, quindi, prendetevi due minuti di pausa e andate a spulciarvi il vostro .htaccess avendo cura che non contenga, alla fine del file, una riga che richiama un file in /tmp.

Tutto è bene ciò che finisce bene. E spero che il burlone che si è divertito col mio .htaccess abbia le ragadi anali per tutto il resto della sua vita, perchè mi ha fatto prendere uno spavento assurdo.

L'Open Source, quando funziona, e quando no.

Il titolo può fuorviare. In realtà non sto scrivendo di ambiti in cui funziona la politica opensource, e altri in cui non funziona: ho avuto un'interessantissima discussione a proposito di questo col mio amico Antonio, su Facebook (chi dice che ci sono solo idioti?), e forse potrei riportarne gli esiti qui, tuttavia adesso, in questo post, voglio parlare di qualcos'altro. Qualcosa che mi preme, che ho visto succedere più volte, che affossa, molte volte, i progetti open.

Leggevo proprio l'altro giorno infatti il post di Emanuele, che consiglio a tutti, il quale illustra come nasce e come cresce un progetto open, le dinamiche che lo portano alla vittoria, al fallimento, allo stallo; ebbene, il carissimo Emanuele ad un tratto, verso la parte finale dell'articolo ha parlato di qualcosa a cui tengo veramente molto: l'essere poi realmente open. Questo non ha molto a che fare con la licenza, ovvero: ok, ovviamente devi licenziare il tuo progetto per essere realmente aperto, ma, quando le persone cominciano a modificare il tuo codice, devi essere in grado di apprezzare tali cambiamenti, ed un bravo sviluppatore (soprattutto un bravo project manager) ha la sobrietà e la lucidità di giudicare codice concorrente dall'alto, senza far scendere minimamente in campo l'orgoglio.

In molti purtroppo, hanno ridimensionato il fenomeno dell'opensource, non perchè non funzioni, ma perchè alcuni progetti molto spesso per una ripicca di qualcuno hanno subito ritardi, stalli, portando poi ad un nulla di fatto. È questo poi il motivo per cui GIMP è ancora fermo e non vengono rilasciate versioni stabili da eoni, così come accade per Compiz. Tutti progetti cari al buon telperion, che ne parla come un padre di un figlio che va male a scuola; ci espone di una fantastica patch per GIMP che ne modifica sensibilmente l'interfaccia grafica, portando in alto i controlli dello strumento che si sta utilizzando.

Proposta tale patch, quale risposta viene data? "No ma, noi abbiamo deciso così, guarda, è facile: fai un fork e applica il tuo cambiamento".

Ma siete scemi? L'ottica del forka o muori è morta da anni. Bisogna essere dei leader calibrati per saper condurre un progetto in totale apertura, e se non lo si è, preferisco accettare che mi venga chiuso il ciclo di sviluppo, piuttosto che vedere esclusi tutti i miei contributi. Ci sono un po' di progetti che, grazie a queste alzate d'ingegno, sono rimasti fermi anni anzichè portare la ventata d'innovazione che il loro manifesto prometteva: è ora di smetterla con quest'ottica dittatoriale del "si fa come dico io". No: si deve fare cos'è meglio per tutti. E cos'è meglio per tutti si vede, semplicemente usando il programma, provando le patch concorrenti. Potrebbe sembrare che il tutto rallenti, ma in realtà se si cominciano a scartare i contributi esterni, i tempi si faranno ancora più stretti. E col tempo l'apporto di codice al GIT del progetto calerà drammaticamente, perchè in un'ottica del genere, o sei pagato, o sei fortemente legato (in maniera sentimentale, dico) ad altri membri del progetto, oppure non ci stai, a fare la pecora.

L'opensource è anche fantasia, e chi non lo capisce merita che il proprio progetto affondi.