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.

Mobile OS e durata della batteria: mh?

Troppe volte ho letto in giro che i pareri sulla durata della batteria degl smartphone sono discordanti. Un po' come quelli sui laptop. Questo articolo vuole quindi essere una bonaria provocazione, a chi non sa di informarsi, e a chi sa di non sproloquiare tanto per dire, perchè è inutile parlare di esperienza propria come univoca quando si tratta del fattore di autonomia di una macchina, dato che, diciamolo una volta per tutte, questo fattore è determinato ed è fortemente legato all'uso.

È infatti diffusa la tendenza a dire: "Ah ma questo PC fa tot ore", oh "fantastico, questo telefono va tranquillamente per due giorni"; no. Prendete tutti piuttosto l'abitudine di dire "Per come lo uso io, il device ha questo tempo di autonomia". Perchè è vero che grossomodo dato lo stesso amperaggio, si possono avere risultati non dissimili, ma è ovvio, per esempio, che un Android con sette homescreen attive piene di widget autorefreshanti e con seimila servizi in background, magari che fanno un uso pesantissimo della rete, avrà un'autonomia ridicola rispetto allo stesso terminale con molte più cose disattivate e soprattutto meno widget da refreshare.

Il ghiribizzo di scrivere questa piccola avvertenza mi è venuto leggendo soprattutto alcune dicerie sul fatto che la batteria di un Nexus S duri meno di quella di un iPhone 4. Ridicolo: è ovvio che, data la potenza della batteria simile, e dato l'hardware, è normale che durerà meno la batteria alla quale si attinge in maniera maggiore; io stesso ho visto crollare iPhone 4 e 3Gs di fronte al mio Desire per il solo fatto di avere molte più porcate in background di quante non ne avessi io, tuttavia non vado a sbandierare nulla in faccia a nessuno.

Ordunque, risparmiare batteria è un compito difficile, e chi si deve arrendere, si arrenda: esattamente come una compilazione di GNOME Shell da GIT può massacrare la carica del nostro laptop, anche in Android questo avviene. E come sempre, è inutile dare consigli scemi come installare un task manager che poi si rivela essere solo un ciucciacarica in più. Basta fare un uso decente del proprio telefono/computer, e, soprattutto, minimizzare quelli che sono i servizi che hanno accesso alla rete mentre non state usando il dispositivo.