14 Dec 2012
In questi giorni mi sono passate per le mani un sacco di email: una tra quelle che mi hanno colpito maggiormente è proprio quella di "addio" del kernel Linux all'architettura 386. Uno tra i supporti più antichi all'interno del kernel, tanto che tutte le distribuzioni "cardine" fino a non molto tempo fa continuavano a voler supportare con ottimizzazioni varie ed eventuali anche un'architettura antica come questa.
Beh, lungi da me piangere una modernizzazione dell'infrastruttura. Come da mail, questo comporta una riduzione della complessità e anche qualche miglioramento in quanto a performance (meno righe di codice, bla bla bla), quindi non posso che esserne contento. La nostalgia risale al fatto che io abbia ricordato come anni e anni fa scaricavo distribuzioni -i386, anche se una delle ultime che scaricai fu Arch Linux che, in avanti rispetto ad altri, ottimizzava già per i686. Che bella cosa.
Riporto integralmente il commit message di Linus Torvalds:
Merge branch 'x86-nuke386-for-linus' of git://git./linux/kernel/git/tip/tip
Pull "Nuke 386-DX/SX support" from Ingo Molnar:
"This tree removes ancient-386-CPUs support and thus zaps quite a bit
of complexity:
24 files changed, 56 insertions(+), 425 deletions(-)
... which complexity has plagued us with extra work whenever we wanted
to change SMP primitives, for years.
Unfortunately there's a nostalgic cost: your old original 386 DX33
system from early 1991 won't be able to boot modern Linux kernels
anymore. Sniff."
I'm not sentimental. Good riddance.
* 'x86-nuke386-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, 386 removal: Document Nx586 as a 386 and thus unsupported
x86, cleanups: Simplify sync_core() in the case of no CPUID
x86, 386 removal: Remove CONFIG_X86_POPAD_OK
x86, 386 removal: Remove CONFIG_X86_WP_WORKS_OK
x86, 386 removal: Remove CONFIG_INVLPG
x86, 386 removal: Remove CONFIG_BSWAP
x86, 386 removal: Remove CONFIG_XADD
x86, 386 removal: Remove CONFIG_CMPXCHG
x86, 386 removal: Remove CONFIG_M386 from Kconfig
:')
L'immagine non c'entra niente, è Python, ma mi piaceva molto.
Image courtesy of nyuhuhuu
12 Dec 2012
Ebbene: adesso questo blog è basato su WordPress 3.5.
Era da tantissimo che non facevo un post così corto solo per brevi aggiornamenti tecnici; su HTML.it è uscito una settimana fa un articolo (bozza corretta dal sottoscritto) che illustra le novità di WordPress 3.5 nel dettaglio; la cosa più bella sembra essere la nuova media library, che finalmente è stata portata al "next level" dopo essere stata per un bel po' nel mirino degli sviluppatori, fino alle ultime release.
È Natale, quindi vi metto una zucca di Halloween a forma di W di WordPress. Non c'entra niente, ma era un secolo che desideravo infilare questa immagine in un post. Godetevi questo capolavoro di open source.
Photo courtesy of Eric M. Martin
07 Dec 2012
Sono disponibili le slide del mio talk al Linux Day 2012, dove mi sono un po' allargato rispetto al solito Linux, e ho parlato più diffusamente di imprese che vogliono fare open source, dando loro 5 parole chiave per iniziare a farlo davvero senza che poi rimangano in qualche modo scottate. Ho spaziato, per ogni punto, illustrando (poco) brevemente alcuni casi di studio di successo come Android, o Ubuntu, o Red Hat - ma anche progetti comunitari come GIMP e Nessus.
Per ognuno di questi ho evidenziato alcuni pregi, ma anche i difetti che potrebbero portare il contributore a scoraggiarsi, e venire meno per quanto riguarda la forza lavoro del progetto stesso.
I 5 punti sono, in sostanza:
- Un team dedicato - per raccogliere i feedback, gestire la comunità e coordinare il progetto, anche in maniera poco invasiva se necessario più spazio per la community;
- Git - oggi tante delle librerie che sono nate quasi per scherzo come progetti open senza Git non ci sarebbero. Utilizzare Git e conoscerne le meccaniche tecniche e psicologiche è utile ad un'azienda per racimolare contributi preziosi al proprio software. Fosse anche solo una pull request;
- Agile - per coordinare una comunità ampia è necessario un workflow definito ma che lasci libere le menti di partorire la loro idea. Con l'approccio agile si ottengono dei benefici in questi sensi;
- Community - perché senza comunità, e senza un elevato livello di attenzione verso questa, non puoi dire di essere veramente qualcuno che ha a cuore l'open source e la openness del proprio prodotto;
- Standard - seguire gli standard è un obbligo per chi fa open source: non è possibile che chiunque mette mano ad un software debba dover imparare notazioni nuove o astruse, o legacy.
Una volta seguite alla lettera queste 5 parole chiave, e avendo creato una situazione win-win per l'azienda e la community, il consiglio: don't fuck around, and kick asses through OSS. Imperativo categorico, direi.
06 Dec 2012
Da romanticone nostalgico quale sono, oggi avendo qualche minuto libero mi sono concesso una carrellata di screenshot non solo miei ricordando una serie di episodi, eventi, personaggi che hanno attorniato la mia vita di linuxiano, specialmente quando ero ancora nella fase di "nerd in crescita", dove le ragazze le guardavo col cannocchiale (e le vedevo anche piuttosto piccole anche lì, a dir la verità), ma dove col computer per certi versi smanettavo davvero.
Oggi ho smesso di compilare un sacco di roba da Git, ho smesso di recensire i rami di sviluppo delle applicazioni, ho smesso di fare un sacco di cose un po' per mancanza di interesse, dato che ormai viene tutto sviluppato in seno ai desktop environment (bene o male), un po' per voglia di stabilità e di cose che funzionano. Dato che, ovviamente, non ho mai creduto che per avere una "cosa che funziona" si debba necessariamente comprare un Mac: il fatto che sinora non abbia mai perso un secondo di produttività significa che ho insindacabilmente ragione.
Però restano i tempi: i tempi che furono, tempi in cui conoscevo gente e facevo cose, non consapevole come non lo erano nemmeno loro che ciascuno di noi poi sarebbe diventato un pezzettino dell'open source in salsa italiana nel mondo, chi per alcuni meriti, chi per altri. Particolare attenzione l'ho dedicata a questo screenshot.
Viene dal blog di Andrea Cimitan, al tempo conosciuto solo come Cimi, e dentro ci sono un po' di cose a cui sono affezionato, del panorama open source che è e di quello che fu:
- GNOME 2.x
- Compiz (quello vecchio)
- Clearlooks
- Arch Linux (col logo vecchio, vintage da paura)
Col tempo ci siamo dati tutti un po' un contegno, ma all'epoca eravamo (Andrea un po' meno) un gruppetto di nerdoni che stavano là, a parlare, a compiere hack. Immagino che anche il Cimi leggerà questo post, e sorriderà un pochetto. In fondo, quando tutto era meno "sicuro", ci si sentiva più una grande famiglia: adesso non è meglio, né peggio. I tempi sono cambiati.
Ma a volte, davanti al focolare, mi viene ancora voglia che i tempi siano quelli che furono, di avere del tempo libero da dedicare ai test più assurdi, e macchine a disposizione per riparare agli eventuali danni usando blasonati manuali e anche qualche intuizione. Bisogna guardare avanti, ma anche guardarsi alle spalle ogni tanto fa bene, oltre che far venire la lacrimuccia.
04 Dec 2012
Non credo di essere mai rimasto soddisfatto di un telefono, così come sono rimasto soddisfatto del Sony XPeria P, per un numero notevole di ragioni, essenzialmente a favore (in maniera mostruosa) dell'hardware che lo compone. Una serie di parti interne ottime, con in più a coprire il tutto una scocca in policarbonato da fare invidia anche al migliore degli iPhone, persino in quanto a design: le misure dei nuovi display di Apple infatti sono ripercorse precise da questo handset antesignano dell'iPhone 5, con al di sotto anche una "striscia" di vetro che, trasparente e con luci interne, provvede a tutto quello che è full touch nel dispositivo.
Tutto questo purtroppo ha due tipi di drawback: per prima cosa per riparare l'XPeria P serve un cacciavitino, dato che la scocca impone la chiusura "ermetica" e non a cerniera. Dal punto di vista del software invece il tutto risulta, per una serie di fighetterie tra cui la suddetta striscia di vetro con illuminazione interna, molto complicata da gestire. È ciò di cui mi sono accorto nel momento in cui ho provato a smanettare con il sistema operativo del telefono: installando versioni comunitarie di Android, non riuscivo ad ottenere gli stessi benefici della ROM ufficiale, se non meri miglioramenti prestazionali. Se la ROM di Sony infatti è un pianto continuo riguardo le prestazioni, anche se per fortuna non è eccessivamente bambinesca come look, purtroppo è anche l'unica che per ora funziona in maniera decente: installando un qualsiasi flavour di terze parti di Android ho assistito ad un decollo del telefono, come velocità, ma ad un comportamento assolutamente arbitrario dei led di notifica, delle luci inserite nel vetro, e dell'accensione del monitor sotto carica - che nel caso specifico provocava l'accensione di tutto il terminale.
Questo dipende semplicemente dal fatto che parecchie cose sono rilasciate, per questo terminale, senza alcuna specifica, quindi nessuno sa bene come vengano gestite alcune piccolezze. E quindi mi si accende lo schermo di notte. E quindi il led di notifica si accende quando vuole. E quindi battery drain. E quindi le luci all'interno della barra di vetro si comportano come delle renne irrequiete. Niente da fare, torno alla ROM Android di fabbrica. Ed è questa l'intenzione che mi ha portato a vivere un incubo di qualche ora: installando un'altra ROM devo aver sbagliato qualcosa (o forse no?) perché mi sono ritrovato con in mano un inutile pezzo di ferro. Esattamente: brick del telefono. Ho avuto la presenza di spirito di non lanciarlo dalla finestra, e ho capito che per fortuna era un soft-brick, ossia nulla di rotto ma molto di grave: dopo una rocambolesca esperienza al di fuori di qualsiasi manuale (e di qualsiasi forum di supporto) sono riuscito, ripristinando una vecchia immagine di sistema per far leggere almeno l'indispensabile a FlashTool, a ripristinare il telefono ad uno stato funzionante. Con un sospiro di sollievo, ho pensato a cosa i produttori potrebbero imparare dall'hacking.
Produttori, non rendete i vostri telefoni delle gabbie dorate. I nostri smartphone sono nostri: rendetecene libero l'uso e l'abuso. Evitate la fighetteria, oppure documentatela adeguatamente perché la community possa costruirci dei buoni hack sopra. Mi viene, per esempio, in mente il caso di BLN: un simpatico hack per supplire alla mancanza di led di notifica del Nexus S; cari produttori, rendete i vostri terminali semplici, senza la necessità di dover leggere dei manuali anche solo per sbloccarne il bootloader - o peggio, per installare un binario e basta.
Fatelo, e vi assicurerete quello per cui Google e Samsung vi stanno soffiando tutta la clientela: dei terminali su cui le persone possono mettere facilmente le mani, e una comunità che lavora attivamente sui vostri prodotti. Ormai lo sapete, i mercati sono conversazioni, e se è vero che sulla corta paga il marketing del device, sulla lunga distanza a pagare è il marketing della community di supporto. Perciò non fateci brancolare nel buio. E datemi 'sta documentazione delle lucette che stanno nel mio XPeria P. :D
Photos courtesy by harald walker - 1 & 2
