27 Aug 2012

Cinque falsi miti su Arch Linux

Soprattutto in questi ultimi tempi, si è fatto un gran parlare di Arch Linux su alcuni media (specialmente Twitter e Google+) relativamente alla cerchia solita dei Linux user italiani - nonché alcuni blog. Questo mi ha convinto a rispolverare un grande classico per pubblicarlo, ossia i cinque più grandi falsi miti su Arch Linux. Arch è una distribuzione inflazionata, infatti, e col tempo è stata testata praticamente sulle macchine di chiunque: alcuni hanno avuto l'onestà intellettuale di dire "non è una distro che fa per me"; altri hanno semplicemente messo in giro FUD diffondendo opinioni squisitamente personali spacciate come fatti oggettivi, cosa che per il modus operandi dialettico del sottoscritto trasforma queste affermazioni in cazzate.

Dato che sempre più spesso capita di farsi il sangue amaro su persone che non hanno ben chiari filosofia e obiettivi del progetto Arch Linux, ho pensato quindi di stilare, e qui concludo con il preambolo, questo piccolo Bignami che spero torni utile a ciascuno di noi, in un qualsiasi thread di Google+, una conversazione di Twitter, o quando pensiamo di stare per pronunciare (si, noi arcieri) un'offesa marcata contro gli stessi sviluppatori. Ché non sono mica solo quelli che se la prendono facilmente, a scagliarsi contro Arch Linux.

È una rolling release quindi è meno sicura/stabile

Sbagliato. Per due motivi: essenzialmente tutto il lavoro di sicurezza sul software open source viene svolto upstream. Le patch che vengono applicate ad esempio dal ramo Security di Debian sono backport di codice che rende l'applicazione maggiormente sicura ad una versione meno recente, in modo che venga tappata la falla in quella specifica versione del pacchetto. Una distribuzione rolling release, invece, ha cura di fornire all'utente, bene o male, sempre l'ultima versione del pacchetto disponibile; per questo motivo, possiamo dire che le distro rolling release sono orientativamente sicure quanto le distro a ciclo di rilascio periodico - se non di più, ove il patching e il backport del codice non avvengano in tempi ragionevolmente brevi.

Per la stabilità il discorso è lo stesso: l'ultima versione di un software upstream incorpora anche patch provenienti da tutte le distribuzioni. Quelle poche volte che il lavoro di aggiornamento riguardo un bug di stabilità non viene svolto upstream, nulla vieta agli sviluppatori (o agli utenti, dato che è assunto che gli utenti di Arch Linux abbiano tale capacità), se non vogliono attendere, di applicare la patch di un'altra distro al pacchetto e rilasciarlo subito.

Se invece si tratta di bug chiusi upstream, la nuova versione sarà migliore. Le distribuzioni a rilascio periodico invece dovranno attendere che il ramo instabile diventi stabile; per bug non gravi che affliggono un numero moderato di persone, questo può essere un problema.

Inoltre, Arch Linux dispone di un repository Testing, dove vengono testati moltissimi pacchetti prima del rilascio nel ramo stabile. A volte vengono persino creati dei repository ex-novo per impedire che nuove release di un software contaminino la stabilità dell'ecosistema dei package che "vivono" all'interno di Core ed Extra (i due repository che essenzialmente costituiscono il ramo stabile di Arch Linux).

Pacman non è all'altezza di APT/RPM

Falso. Pacman implementa meccanismi largamente in voga nelle distribuzioni Linux, ma in maniera più semplice. Ad esempio il signing dei pacchetti: viene fatto in maniera meno complessa di APT, e molto più user-centrica. È il tool chiave di Arch Linux, e se è vero che non è da meno a gestori di pacchetti più blasonati fornendone le stesse funzionalità, un buon argomento di conversazione potrebbero essere gli innumerevoli miglioramenti di cui Pacman avrebbe bisogno. Dire semplicemente che "Pacman fa schifo" è una goliardata che merita di finire nell'Olimpo delle frasi stupide del panorama Linux.

Un aggiornamento può distruggere il sistema

Falso. Anche se molte persone hanno pensato che fosse vero vista la loro pervicacia nel forzare alcuni aggiornamenti nonostante fosse scritto ovunque di non usare assolutamente l'opzione --force su uno specifico package. Nonostante ci sia stato quest'ultimo caso eclatante (l'ultimo, epico, aggiornamento di glibc), avevo sentito più volte l'affermazione legata anche ad altri aggiornamenti critici. Il punto è che Pacman (per scelta, non ce lo scordiamo) non gestisce i file di configurazione e gli aggiornamenti da fare a questi ultimi. Questo compito in Arch Linux è lasciato all'utente il quale ha come assistenti un ottimo wiki, e soprattutto le indicazioni non appena un pacchetto viene installato.

Utenti che aggiornavano alla cieca quindi si sono visti scomparire il sistema in stato consistente da sotto i piedi, semplicemente perché prima di un reboot non hanno letto il log di Pacman che diceva di aggiungere una banale opzione, una voce aut similia ad un file di configurazione.

Con chi te la vuoi prendere in casi come questi? Ma coi developer naturalmente. I quali avevano l'impegno morale e l'imperativo categorico di telefonarti a casa per avvisarti. Seh.

Di solito l'argomento più efficace contro le persone che affermano una cosa del genere è che forse potrebbero uscire dall'analfabetismo e leggere il log di Pacman, specialmente dopo un aggiornamento ciccione da centinaia di megabyte - o peggio, qualche giga.

Gli utenti di Arch Linux sono spocchiosi

Sbagliato. In realtà, se le cose vengono chieste con cortesia ed educazione, è possibile trovare negli utenti di Arch Linux una risorsa inestimabile in termini di case study, bug affrontati, bug risolti, ecosistema open source, e soprattutto bei birrozzi in compagnia.

Quello che amo della comunità di Arch Linux, allo stesso tempo, è quel latente senso di MIT anni '70 per cui se dici una cavolata, nel giro di trenta secondi lo sapranno tutti (stile condominio con comari annesse) - e comincerà a breve una serie di battute sarcastiche nei tuoi confronti. Niente di cui lamentarsi riguardo la cattiveria comunque: di solito sono prese in giro bonarie (o binarie?) di chi si diverte a ostentare un po' la sua superiorità nei termini della questione che viene discussa sul momento.

Ci sono persone che percepiscono questa cosa come una barriera, e me ne dispiaccio perché ho incontrato spesso persone conosciute sul canale italiano di Arch Linux, o sulla board nazionale, e non mi sono mai trovato male. Mai e poi mai.

In coda, un monito: se un utente Arch Linux - specialmente di quelli della vecchia guardia - sta dicendo che avete torto durante un dibattito su Linux, di solito è bene rivedere le proprie posizioni. Perché state effettivamente, al 90%, avendo torto; e se continuate a dare addosso a questo genere di persone, che sono abituate a dimostrare che quello che dicono è vero coi fatti, è probabile che vi sbugiardino su tutta la linea con una serie di prove schiaccianti. Alla faccia della spocchia: abbiamo solo sempre ragione :D

Gli sviluppatori di Arch Linux sono pazzi e inseriscono nuove feature a caso e in maniera improvvisa

Sbagliato. O meglio: gli sviluppatori di Arch Linux inseriscono nuove feature in maniera improvvisa ma non sono né pazzi, tantomeno lo fanno a caso. In Arch Linux la necessità di aggiornamento è completamente a carico dell'utente, e può capitare, come sopra, che alcuni update siano leggermente più difficili da gestire che premere il tasto y sulla tastiera.

È un rischio potenziale per qualsiasi aggiornamento, ma ci si può accorgere di questo con dei piccoli trucchetti: uno è tenere d'occhio le news, che informano gli utenti di qualsiasi aggiornamento farraginoso. L'altro piccolo trick è guardare la lista dei pacchetti in aggiornamento prima di fare un update casuale a tutto quanto l'ambaradan: di solito pacchetti come glibc possono essere leggermente più pericolosi ed è consigliato prestare attenzione quando si aggiorna il core del sistema. Questo comprende pacchetti come systemd (si, avete letto bene, systemd), kmod, il kernel Linux, o Pacman.

Inoltre, personalmente ci sono alcune settimane in cui ho necessità di essere più produttivo che in altre. In quei periodi evito di toccare lo stack software della mia macchina, perché so che anche un piccolo cambiamento potrebbe inficiare la mia produttività e il mio workflow. Sono piccoli consigli, metterli in pratica non costa veramente niente e la vostra vita da arcieri ne guadagnerà.

Tradotto, questo pistolotto può essere sintetizzato in: se aggiorni alla membro di segugio non è colpa mia.

Arch Linux non è un sistema pensato per rispondere ad esigenze brainless. A soddisfare i vostri bisogni dovete pensarci voi, ed il sistema vi mette a disposizione tutto ciò che serve per farlo. Quindi, quando accendete la vostra macchina, verificate di aver acceso prima anche il cervello. È gratis.

Image courtesy of Jason Ryan

24 Aug 2012

Attenzione App.net: soffri dell'effetto Instagram

Mi sono preso un paio di settimane dall'osservazione dei soliti flussi di progetto che seguo. Ho deciso, nel frattempo, di mettermi a riflettere sul caso di App.net, startup che vuole costruire, grossomodo, un clone di Twitter in maniera totalmente aperta - anzi, come dicono gli stessi sviluppatori, "com'era Twitter prima di diventare una media company". Sono delle buone premesse, ottime. Come molti, sono anch'io indignato dal comportamento che Twitter sta avendo verso i suoi sviluppatori di terze parti, verso la sua community, e di riflesso nei confronti delle proprie API.

App.net vuole proporre le basi per un social feed totalmente open source: è un ottimo progetto, ma bisogna stare attenti a come ci si muove; per certi versi, ha ragione Andrew Chen, pensando che questo progetto possa costituire una backbone della "next version" del web che tanto amiamo. Il timing, come ha anche detto Fabio Lalli nel thread di discussione che ho aperto su Indigeni Digitali, è impeccabile: Twitter chiude, e mentre lo fa arriva un progetto che si presenta come un potenziale stakeholder dell'intera Internet, per chi ha l'occhio un po' più lungo, che da priorità all'utente anziché alle pubblicazioni esterne (annunci, promoted "roba"). Io stesso sono rimasto affascinato da App.net e sono stato piuttosto tentato di finanziare il progetto da early adopter con i miei 50$.

[vimeo 48111032 w=550]

Peccato che fossi al verde, e soprattutto non credessi completamente nel progetto, cosa che non è vera nemmeno adesso: App.net infatti è ottimo come case study, ma all'atto pratico soffre secondo me paurosamente sia sul piano di impresa, che rispetto ad altri progetti concorrenti. Ho denominato le debolezze di cui soffre "effetto Instagram" in un mio post pregresso. App.net rischia grosso se non diversifica in maniera sostanziale quello che sta facendo.

50$? Really?

Dedico un punto a parte alla questione business plan: la faccio anche molto breve. 50 dollari l'anno? Veramente? Ehi App.net, avrai dei server immagino. E queste macchine hanno un costo; come pensi di monetizzare la tua piattaforma, e ricavare dagli utenti l'utile per te e sperare di coprire al contempo l'architettura hardware senza la quale tutto il meraviglioso stack software da te progettato diventa semi-utile? Certo, gli sviluppatori pagano il triplo, ma fatti i conti secondo me è qualcosa che non sta in piedi: si dovranno trovare altre vie per rendere sostenibile questo modello, e non è certo spillando 50$ a persona che una piattaforma riesce a stare a galla.

Poi, se il founding fatto sinora copre tutte le spese compresi gli stipendi degli sviluppatori e il parco macchine, sono contentissimo eh. Però insomma. Mi farebbe piacere leggere qualche dato ufficiale.

Effetto Instagram per App.net

Ho visto così tante startup soffrire della mancanza di un reale asset non duplicabile che potrei farci un bel bollino "Instagram effect". Appena ho letto l'intento di App.net, mi è venuto in mente che era una cosa fichissima; poi ho pensato un attimo a quali potevano essere i concorrenti. Fare si che ognuno di noi abbia il proprio social feed aperto sia allo sviluppo che anche lato server tramite strutture open source è un compito non da poco, ma attualmente un campo minato in quanto a concorrenza. Twitter ha molto del proprio backend aperto, e del frontend non parliamone: Boostrap è un toolkit clamoroso.

Per quanto riguarda le API, Twitter può fare marcia indietro ed investire col proprio cingolato da dieci tonnellate la povera monovolume che al momento è App.net (la cui interfaccia grafica non è, mi spiace dirlo, delle più invitanti).

Un altro stakeholder potrebbe essere Google+: con una decisione repentina, mettendo a nudo il proprio core e offrendo delle API che facciano gola ai developer, potrebbe mettere KO App.net in quattro secondi netti. Quelli che passano dal rilascio aperto della tecnologia al momento in cui la notizia arriva alle orecchie di The Verge (o di HTML.it, per noi italiani). Google potrebbe avere un peso in questo ecosistema? Certo: dato che, come ci dice Andrew Chen, un progetto come quello che sta portando avanti App.net potrebbe essere alla base dell'Internet di domani, a me non dispiacerebbe se una compagnia come Google si rendesse protagonista di questa innovazione - o così, o naturalmente effettuando dei commit al progetto di App.net. In fondo è grazie a Google se abbiamo delle ottime librerie da studiare completamente aperte, e se il mondo intero può mettere le mani su un sistema mobile open source senza doverselo riscrivere da zero.

Conclusione: vai così App.net, ma non dire che non t'avevo avvisato

Personalmente, nonostante queste premesse di effetto Instagram per quanto riguarda il business di App.net, credo che difficilmente Twitter farà un passo indietro sulla propria politica (disgustosa, indeed) riguardo le API; allo stesso modo, dubito fortemente che Google vorrà invischiarsi in qualcosa come il "costruire un pezzo dell'Internet di domani". È per questi motivi, essenzialmente, che credo che comunque App.net sia imprescindibile, vada tenuto fortemente d'occhio, e senza dubbio mi auguro che consegua sempre più obiettivi positivi nonostante le mie previsioni.

Se non altro Dalton Caldwell ha l'immenso merito, esattamente come altri prima di lui, di aver sollevato un tema decisamente importante sia per gli sviluppatori, sia per l'ecosistema di startup "editoriali" aut similia che verranno, sia per tutti quegli utenti che, un po' più coscienziosi, prestano attenzione alla proprietà dei dati che consegnano quotidianamente ai social network, e alla propria dignità di elemento fondante dell'empowering di una piattaforma.

Non è mai bello prostituire i propri contenuti. Torniamo ad esserne proprietari ad ogni effetto.

Ah: piccolo reminder. Dalton Caldwell è il fondatore di PicPlz. Ironia della sorte. :)

Photos courtesy of  Bernard Goldbach, Aaron Parecki

23 Aug 2012

Rapporto Censis sull'impatto della cooperazione sull'economia in Italia

Quando ci si chiede quale valore abbia la cooperazione per l'impresa oggi, è fondamentale tenere a portata di mando le fonti, soprattutto quelle ufficiali, che confermano che tramite la cooperazione è possibile che si verifichi un processo virtuoso, e quindi crescita economica.

L'open source alla sua base ha proprio questi valori, ed è per questo che sono stato felicissimo di apprendere da Dario Carrera tramite il gruppo Facebook di Hopen, che è stato stilato dal Censis il primo rapporto sull'impatto della cooperazione nell'economia italiana. Ho cominciato a leggerlo, ed è ottimo avere dei numeri alla mano per confrontarli con le proprie convinzioni e con i propri casi di studio.

È anche sollevante vedere come i grafici siano tutti in salita, segno che non solo non sono (siamo?) pazzi, ma che Hopen e OuiShare raccontano un modello di società perfettamente sostenibile, il quale può essere anche la soluzione, implementato per passi, a parecchi problemi che affliggono le aziende oggi.

Spero di terminarlo a breve, intanto beccatevi il link ufficiale ;)

Rapporto Censis sull'impatto della cooperazione sull'economia in Italia

21 Aug 2012

EgoRego intervista il sottoscritto

Un'intervista è sempre un modo per confrontarsi con se stessi a partire dalle domande che l'intervistatore pone. Sono stato intervistato in questi giorni da EgoRego, una internet company con sede a Roma; l'intervista è stata pubblicata oggi, sul loro blog, e tratta dei soliti temi di cui mi occupo: open source, informazione, editoria.

Colgo ancora l'occasione per ringraziare Giulia di avermi ospitato - e di essersi letta tutte le mie farneticazioni per assicurarsi che fossero pubblicabili. ;)

20 Aug 2012

Fedora 17 e le tentazioni estive

Lo so, lo so: è uscita da un sacco di tempo, eppure Fedora 17 mi tenta solo ora. Sarà che ogni anno durante il periodo estivo mi vengono pensieri riguardo le distribuzioni Linux e vengo sempre, dico sempre, tentato dalla nuova ottica di Fedora vista come GNOME OS. Tra l'attenzione particolare risposta (da sempre, direi) in GNOME e il fatto di essere stata la prima tra le distribuzioni leader ad adottare systemd infatti, mi ha sempre fatto in questi ultimi anni una particolare simpatia, anche data dal fatto che nonostante il ciclo di sviluppo semestrale ha una politica sull'aggiornamento dei pacchetti molto permissiva e, se vogliamo, quasi a contatto con il metodo rolling release che è quello che io preferisco.

Insomma, il risultato è che dalla mia bella workstation Arch Linux + KDE ho messo a scaricare il torrent del DVD di installazione di Fedora, dato che sicuramente per motivi di tempo devo cambiare distro sul netbook e, avendo una partizione vuota, voglio anche dare una chance a GNOME sul nuovo laptop, il quale ha visto GNOME Shell solo una volta, di sfuggita, e anche configurata piuttosto male.

Vediamo se la distro targata GNOME e sponsorizzata Red Hat riuscirà a farmi cambiare idea. Altrimenti, poco male: ho sempre il mio ambiente da nerd finemente configurato, sino al più piccolo dettaglio, e pronto ad accogliere il figliol prodigo dopo questo peccaminoso atto.

Vi faccio sapere.