Shuttleworth, ACPI, e il software proprietario in Ubuntu

- Open Source

Mark Shuttleworth

Nelle ultime ventiquattro ore, niente avrebbe potuto stupirmi più della dichiarazione recente di Mark Shuttleworth (il papà di Ubuntu, per capirci) secondo cui ACPI è il male supremo e non solo: permettere ad una tale tecnologia di venire utilizzata nell’era del software open source (per come la protodefinisce lui) sarebbe un fallimento nostro nel tentativo di smarcarci dai blob proprietari.

In sostanza la sua idea di portare l’innovazione e il codice che la rappresenta direttamente all’interno del kernel Linux, upstream, è ottima, e non la discuto. Un po’di debunking sul suo pensiero però farebbe bene. Mentre lui si proclama paladino dell’open software e in buona sostanza dell’open hardware, gli Ubuntu Phone vengono pianificati dai vendor con un’interfaccia molto simile ad ACPI, dove il kernel è Linux ed è grossomodo upstream, ma i blob proprietari utilizzati sono moltissimi.

We DO live in an era where any firmware code running on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you.

È vero Mark. Hai piuttosto ragione. Mister “Io sono stato sull’Enterprise e voi no” Shuttleworth continua il suo ragionamento in maniera sensata:

If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.

Per estensione, grossomodo, data l’invisibilità del codice sorgente di un software lato server, possiamo desumere che sia legittimo catalogare in questo modo tutto il software proprietario: in mancanza di prove, al posto della presunzione d’innocenza introduci lo scenario nel caso peggiore, in modo da prevedere le conseguenze più brutte rispetto ad un’azione specifica. Bene, tutto giusto.

Se. Se. Se non fosse che Mark “Er Mitico” Shuttleworth ha uno scheletro nell’armadio grosso così, perché installando Ubuntu poi compare questo.

Ubuntu One

Ora, non sta a me definire come il patron di Ubuntu dovrebbe comportarsi, anzi, è bene che dica cose del genere perché sicuramente mi riconosco più in queste frasi che nel comportamento fattivo della sua azienda. Copio da Wikipedia le informazioni che ho su Ubuntu One, che credo siano corrette:

Licenza: il software lato server è proprietario – il software lato client è in GPLv3.

Per carità, tutto bello e tutto figo, Ubuntu One tra l’altro funziona anche bene. Ma le cose sono due. O predichiamo bene e razzoliamo bene, oppure se il software proprietario lo equipariamo ad un malware, allora Ubuntu effettivamente include dei malware, esattamente come professa FSF. Esagero? È probabile. Sono nel torto? Può essere. Ma il fondatore di una compagnia il cui core business è la fornitura di servizi attraverso (anche) uno dei pilastri fondato su software proprietario (ovvero Ubuntu One server-side), non può permettersi di dire certe cose senza far seguire alle parole un gesto concreto.

Mi aspetto la release del server di Ubuntu One sotto GPL molto presto.

Photo courtesy of Esther Dyson

Poscritto

Riccardo Padovani, che mi osserva silente ma quando faccio un errore mi bastona subito (e fa bene!), mi fa notare che quello che ho scritto sugli Ubuntu Phone è senza fonte. È vero. Tuttavia, dato che sinora il mercato degli smartphone non ha trattato la questione open driver in maniera “frontale”, ho sfornato quella che a tutti gli effetti è una congettura basandomi sul fatto che i primi dispositivi di test per Ubuntu Touch sono stati i Nexus, che necessitano di blob proprietari nemmeno indiferenti; quindi immagino che anche i Meizu con Ubuntu, più o meno, saranno fatti della stessa pasta.

Telegram: pro e contro

- Web

Telegram

Proprio in questi giorni, uscito dalla sessione d’esame (e rivista quindi la luce del sole) ho deciso di dare una chance a Telegram, sia dal punto di vista della tecnologia pura (quindi esaminarlo abbastanza nel dettaglio lato server) che dal punto di vista dell’utilizzo quotidiano come sostituto potenziale di Whatsapp all’interno del mio flusso di comunicazioni.

Nonostante di solito io sia un tipo che sa abbastanza cosa vuole e cosa aspettarsi, pur trovandolo sostanzialmente un surrogato per ora non totalmente pronto a sostituire uno strumento come Whatsapp (o altri, se ne usate – ma per me sono anche peggio, quindi lasciamo stare), ho toccato con mano alcune novità che hanno un potenziale enorme dal punto di vista della user experience, e che effettivamente me lo hanno fatto apprezzare parecchio, soprattutto dal punto di vista (diciamo pure) lavorativo.

Di seguito quindi, tre motivi identificati da me per cui Telegram non è attualmente una soluzione alle criticità di cui soffre Whatsapp, ma non solo: anche tre ragioni per farvelo stare, ugualmente, molto simpatico come secondo classificato.

Reinventare la ruota non è bello

Viviamo in un ecosistema fatto di tecnologie aperte, oltre che di imprenditori che sanno vendere la propria creatura a un colosso per svariati miliardi di dollari (di cui un bel po’ in stock option); per questo motivo, risulta antipatico creare un proprio protocollo che non sia basato su XMPP per la comunicazione e RSA/OTR per la crittografia, dato che sono tecnologie da sempre presenti nella storia dell’informatica, e sostanzialmente rock-solid dal punto di vista della sicurezza.

Telegram invece si basa su un protocollo proprio, che per quanto ben descritto in molteplici paper e sulla pagina ufficiale (nonché messo in pratica attraverso il codice dei client che possiamo esaminare), è comunque una cosa nuova da studiare da capo, completamente. Mtproto è molto carino come concezione, ma il team avrebbe potuto risparmiare parecchio tempo non creando tutto questo, e partendo invece da quelli che sono dei golden standard. In questo modo invece abbiamo una creatura che per quanto carina, all’interno dei protocolli di comunicazione è in ogni caso un nuovo player che ha da mostrare tutte le sue carte, e da giocarle anche con cura.

È sicuro, ma non troppo

Telegram è più sicuro. Ok, abbiamo capito. Ma questo atteggiamento irritante degli sviluppatori di Mtproto, e di chi consiglia Telegram a sua volta, si scontra con un altro atteggiamento abbastanza deplorevole, e cioè quello di chi, nel frattempo, ne ha scoperto delle gravi falle a livello di protocollo crittografico.

Geoffroy Couprie, sviluppatore per VLC e consulente per la sicurezza informatica, ha scritto l’interessantissimo Telegram, AKA “Stand back, we have Math PhDs!”, dove ha messo alla berlina un po’ di corbellerie insite all’interno di Mtproto (ossia il protocollo usato da Telegram), come ad esempio una falla abbastanza grave nella chat criptata end-to-end, in quanto lo scambio di chiavi Diffie-Hellman viene coadiuvato dal server con un’operazione per cui (facendola breve) ci si espone ad un attacco Man In The Middle – il che significa sostanzialmente che se sono abbastanza furbo da fingermi un tuo server, riesco non solo a intercettare i tuoi messaggi, ma a decriptarli senza problemi.

Vogliamo continuare? Nah, piuttosto, leggetevi anche il thread di commenti sottostante in cui gli sviluppatori di Telegram accusano Couprie di aver scritto inesattezze – cosa in parte vera e rettificata nell’articolo, ma non totalmente: altri dettagli (come quello sovrastante) sono ancora in attesa di una smentita.

Si ma… mia nonna lo usa?

Siamo in tanti ad aver installato Telegram; parecchie persone che lo usano ne incoraggiano l’adozione tra quelli che conosco, e parecchi scettici sempre nella mia cerchia gli hanno dato una chance, alcuni con successo, altri meno. Nonostante questo, però, la curva d’adozione è sempre piuttosto bassa, dato che i numeri di Whatsapp sono stati raggiunti non con un’esplosione singola, ma con una serie di boom progressivi che gli hanno permesso di diventare praticamente la piattaforma leader nel settore del messaging nel mondo.

Certo, le recenti adozioni di massa di Telegram possono avere un piccolo peso per Whatsapp, ma chi ha grosse cerchie di amici ancora fortemente legate al messenger (ormai) di Facebook non sarà così facile da smuovere: le masse si muovono solo con numeri ingenti, e sinora il punto di adozione ingente sembra per Telegram un’oasi alla fine di un lunghissimo tracciato da percorrere in un deserto costellato di ostacoli, tra cui Line con la sua interfaccia bellina, e WeChat che in Cina fa numeri da paura.

Chiaramente quindi, chi non è interessato alla nicchia (a meno che tutti i propri amici non abbiano già fatto il salto) lascerà Telegram al palo.

È open source (almeno, in parte)

Almeno, un pezzo di Telegram è open source. Ed è pure una parte consistente: anche se il server è ancora proprietario per motivi piuttosto loschi (e probabilmente i russi si stanno babbando tutti i nostri numeri di telefono per poi farci chiamare uno ad uno dai Testimoni di Putin), il protocollo è aperto, sviscerabile, e completamente comprensibile, tant’è che infatti le falle di sicurezza presenti sono state rese evidenti da svariati ricercatori che si sono interessati al tema in maniera immediata.

Stessa cosa dicasi con le API, che, ben documentate e altrettanto ben sviluppate, hanno permesso non solo la creazione di un buon client che, reso open source, può essere utilizzato anche a livello accademico per la comprensione di come un’applicazione comunica con il proprio server (in maniera cifrata, oltre tutto), e può chiaramente essere migliorato da una comunità piuttosto attiva. Se infatti l’applicazione per iOS è stata creata dallo stesso team di sviluppo, già il client Android segue dinamiche diverse, dato che la prima versione (immagino come le successive) è stata frutto di un contest, vinto da due programmatori proprio con il client che noi utilizziamo sul sistema operativo di Google.

La open API ha fornito anche l’appiglio per la proliferazione di client per altre piattaforme, approccio che non si ferma solo al mobile: abbiamo infatti anche un client per la riga di comando (compatibile con Linux e OS X), ma anche Telegram per Mac e Telegram per Windows. In mancanza di sforzi “ufficiali”, oltre tutto, anche Windows Phone ha beneficiato di una API con un tale grado di apertura (ormai obbligatorio per questioni di engagement, secondo me), dato che la community anche in quel caso ha colmato la lacuna con dei client completamente “homemade”.

Dobbiamo aspettarci un server open source di Telegram ben presto. Nonostante di solito io creda poco a queste affermazioni, forse in questo caso l’inizio è talmente buono che il progetto si merita un po’ di fiducia durante un periodo di staging proprietario che giocoforza è causato da questioni di fruibilità del codice. E quello che possiamo attendere come passo successivo, è che i client di Telegram/MTproto ci permettano effettivamente di specificare se connetterci a un server ufficiale, o ad un server che abbiamo messo in piedi noi stessi. Perché no? In fondo un servizio decentralizzato di messaggistica mobile sarebbe veramente innovativo.

Altro che balle varie correlate.

Meglio di niente

Whatsapp, si sa, è veramente pessimo sia come implementazione (un XMPP modificato in maniera abbastanza promiscua), che come sicurezza. Se infatti è vero che sono state segnalate delle falle ben chiare che mettono in pericolo la nostra privacy in maniera ingente, è anche vero che oltre questo i developer non hanno fatto gran che per proteggerci da occhi indiscreti, anzi: continuando a fatturare la compagnia si è completamente disinteressata di tutte quelle istigazioni ad attacchi man-in-the-middle, e probabilmente con Facebook al timone il comportamento sarà grossomodo lo stesso.

Telegram, invece, si trova un passo avanti da questo punto di vista: con un protocollo aperto mette in evidenza una sicurezza parecchio maggiore, oltretutto nonostante la presenza di problemi abbastanza rilevanti nell’algoritmo di crittografia, dovuti per lo più alla possibilità di attacchi MITM (anche in questo caso), l’atteggiamento degli sviluppatori sembra costruttivo e – tanto per tornare al punto di cui sopra – l’apertura dimostrata non tanto in fase di progettazione quanto di condivisione del lavoro svolto fa ben sperare, e sicuramente fa da grimaldello per chi cerca un’azienda fornitrice di servizi che ha a cuore in maniera maggiore la sicurezza di uno scambio di informazioni.

È una tecnologia migliore

Quella introdotta da Telegram è inevitabilmente una tecnologia migliore, perché si sposa meglio con i bisogni dettati da un mercato che è stato completamente rivoluzionato, nel bene e nel male, da una certa attenzione per l’aspetto della sicurezza. Anche se non ancora completamente aperta, sulla carta la tecnologia utilizzata da Telegram è decisamente migliore di quella alla quale ci dà accesso Whatsapp. Una persona un po’ attenta a questo tipo di caratteristiche per cui dovrebbe sicuramente considerare uno switch, a meno di non prendere in considerazione anche altri fattori di cui sopra.

Non credo ci sia molto da dire. Uso Telegram da un paio di settimane, affiancato a Whatsapp come messenger principale sul mio smartphone Android e sulle mie macchine. Certamente c’è da lavorarci su. Tuttavia, l’approccio al servizio mi pare interessante, per quanto approssimativo come business plan (chi paga? Pantalone?); c’è solo da aspettare, sicuramente il team si merita un po’ di supporto e parecchi feedback.

Open source: come cambiano i business model

- Open Source

Open Source

The biggest driving factor for software developers to work together with open source is cost. It is much cheaper for them to cooperate through open source than it is to remain isolated with proprietary software, asserted Inktank VP of Product Management Neil Levine. “You can no longer rely on one particular vendor to provide everything you need with regard to technology.”

Un piccolo estratto da un articolo veramente interessante che ho letto oggi, sull’open source e la coopetition, dove viene mostrato come grazie ai nuovi business model portati avanti all’interno di un ecosistema simile i modelli comportamentali adottati dalle strutture di governance e gestione dei progetti divengano man mano più sagge, calibrate, e chiaramente collaborative (e come questo porti ad ammortizzare i costi colmando i debiti tecnici).

Consigliatissimo; specie il paragrafo “Opposing becomes joining”.

Photo courtesy of opensource.com

Twitter Bootstrap, l’interfaccia grafica del web

- Web

code

Oggi ho letto questo interessantissimo post di Dave Winer che espone un notevolissimo punto di vista per quello che riguarda Bootstrap, il framework per frontend development/design distribuito tramite GitHub (open source) da Twitter.

The idea of Bootstrap, as I see it, is to add a layer of standardization between the app developer and the “hardware,” in this case, the user interface offered by the modern HTML 5 web browser. When you view it this way, there’s nothing controversial about it. It’s what engineers always do. When we see complicated chaos, we try to figure out what’s really going on, and produce a simplified and rational view of it. Then all the code that rides on top of the new layer can also be rational and relatively simple.

Sostanzialmente Winer espone una tesi: con Bootstrap si sono venute a creare delle inconsapevoli HIG (Human Interface Guidelines), dato che l’utente riconosce un’applicazione creata con questo toolkit e ne identifica un certo design pattern che lo porta a cercare i menù e gli elementi familiari sempre negli stessi posti, un po’ come funziona per le interfacce grafiche dei computer.

Questo viene stimolato in un certo senso dalla replicazione degli stessi elementi grafici (ad esempio l’aspetto dei bottoni) tra un sito e un altro. In poche parole, Bootstrap è diventato il GTK, il Cocoa del web: un toolkit con cui costruire interfacce, il più popolare, e probabilmente ciò che ha iniziato a definire un livello successivo (come dice anche il post originale) di come è possibile continuare la catena del software nel web.

Photo courtesy of Michael Imbeault

Red Hat / Fedora: RPMDB altered outside of yum

- Linux

Fedora htop

Di recente sulla mia workstation con Fedora ho cominciato a pastrugnare con il package management in maniera indiscriminata, così invece di far fare tutto a Yum che mi dava qualche piccola incongruenza, per installare un pacchetto mi sono avvalso di RPM puro, cosa che ormai a quanto vedo non dovrebbe essere mai fatta, demandando a yum localinstall il compito di installare pacchetti singoli.

Fatto sta, che ho avuto un feedback “strano” dalla mia macchina provando a usare direttamente RPM: ha cominciato a rompermi le scatole ad ogni operazione di gestione dei pacchetti avvisandomi che il database di RPM era stato modificato senza che Yum lo avesse autorizzato.

Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.

Al di là di ogni presa di coscienza del fatto, e procurato allarme (ok, ho scardinato RPM, ho capito), può essere utile rimettere in marcia il nostro sistema senza che mostri più quel feedback che, con tutto il rispetto, ma mi ha fatto prendere un accidente. Mi sono guardato un po’ intorno e ho notato che basta dare un singolo comando per liberarsi di questo peso sulla coscienza:

$ sudo yum clean all

Occultamento di cadavere? Forse si. Ma se la macchina la amministriamo noi, chi se ne importa. Buon lavoro :-)

Photo courtesy of Kaleb Fulgham

Registry npm privato: in cloud con Nodejitsu oppure in-house

- Open Source

Node.js

Proprio in questi giorni, ho letto che Nodejitsu ha cominciato a implementare il proprio modello per i registry privati di pacchetti npm in modo che le aziende possano mantenere i propri package privati su un server in cloud a prezzi comunque sostenibili. Il tutto si basa sull’utilizzo del modulo di Node smart-private-npm; di seguito, un esempio preso dal loro blog dove sfruttano Node.js per fornire un registry privato insieme alla loro libreria, da poco (immagino) resa open source per chi comunque non può permettersi un costo così elevato (perché in startup o per qualche altro motivo) e decide di sostituire al costo della cloud qualche ora di effort e una macchina – o una VPS. Ovviamente io consiglio DigitalOcean che permette l’hosting di droplet su SSD :D

var smartPrivateNpm = require("smart-private-npm"),
    url = require("url");

//
// Configure your private npm. You could load this in from a file
// somewhere.
//
var config = {
  rewrites: require("./config/rewrites"),
  proxy: {
    //
    // Location of the target public npm registry. 
    //
    npm: url.parse("http://user:pass@registry.nodejitsu.com"),
    //
    // Private npm options.
    //
    policy: {
      npm: url.parse("http://user:pass@private.registry.nodejitsu.com"),
      private: {
        //
        // This is the list of 'known private modules'
        // that will always be proxied to the private npm.
        // It is built over time by remembering 'publish' requests.
        //
      },
      blacklist: {
        //
        // This is the list of modules that will ALWAYS be proxies
        // to the private npm, no matter what.
        //
      },
      whitelist: {
        //
        // If enabled: only requests for these modules will be served
        // by the proxy (unless they are 'known private modules').
        //
      },
      //
      // In 'transparent mode' the proxy will always forward to
      // the public registry.
      //
      transparent: false
    }
  },
  //
  // Server options (from 'create-servers')
  //
  http: 80
  https: {
    port: 443,
    root: "/path/to/your/ssl/files",
    key: "your-ssl.key",  // or .pem
    key: "your-ssl.cert", // or .pem
  }
};

smartPrivateNpm.createServer(config, function (err, servers) {
  if (err) {
    console.log("Error starting private npm: %j", servers);
    return process.exit(1);
  }

  console.log("Private npm running on %j servers.", Object.keys(servers));
});

Per l’operazione di pubblicazione dei pacchetti npm su un registry diverso, va semplicemente riadattato poi il comando che andiamo a dare nella shell:

npm publish some-private-code --reg http://localhost/

Ho trovato con cosa giocare stasera dopo il lavoro. In bocca al lupo a chiunque si voglia cimentare, e come sempre grazie a Nodejitsu per tutto l’open source che ci regala.

Photo courtesy of Trygve Lie

Flow: il mio nuovo tema per WordPress è open source

- Open Source

github open source

In due o tre, dall’ultimo restyle del blog che risale a questo capodanno, mi hanno fatto i complimenti per il nuovo tema; effettivamente non c’è voluto molto, ma ho dovuto mettere insieme qualche tassello per permettere la modifica della foto nell’header e qualche altra cosetta. È anche la mia prima esperienza diretta con il responsive web design: finora avevo demandato tutto a framework come Foundation o Bootstrap, ma ho deciso di fare tutto da zero e scrivermi un po’ di media query da solo (con stili associati).

Flow (ho deciso di chiamarlo così) è su GitHub sotto licenza GPL2 per motivi di fork dal tema padre, Lean, a sua volta basato su Underscores; mi sono trovato molto bene a costruire un tema su Underscores, tuttavia anche le opzioni che ha elencato Francesco recentemente non sono niente male, e se dovessi ripartire da zero oggi userei BlankSlate.

Cosa c’è e cosa non c’è

  • Per il momento all’interno del tema è presente la possibilità (implementata nel functions.php con delle specifiche precise) di cambiare l’immagine dell’header, che in questo caso è banalmente la foto circolare. In questo blog c’è la mia, ma di default ho inserito un simpatico capibara.
  • Il codice è quello che è, è mio e ogni scarafone è bello a mamma sua. Ogni lamentela che non alleghi una pull request non verrà presa in considerazione. :D
  • L’aspetto meno simpatico è che ho fatto hardcoding su un paio di cosette come il mio nome e il “gdb ./life” presente nella testata. Al momento non ho in programma di portare questi aspetti ad un livello più pulito e di backend, quindi chi vuole usare il tema lo modifichi tranquillamente. Chi invece ha tempo e voglia di perderci una mezz’ora a implementare un pannellino di configurazione, ha una birra pagata quando ci vediamo.
  • Flow è responsive!
  • Alla batteria, Mike Mangini.

Che altro dire: divertitevi. :)

Photo courtesy of Brennan Bearness

Il mio regno per il 4K

- Tech

4k monitor

The toleration of mediocrity on the desktop irks me.

Così recita Brian Hauer in un suo recente post che ha fatto parlare un bel po’ sviluppatori, hacker e nerd in generale, e devo dire che mi sento abbastanza d’accordo. Partiamo con un po’ di background, che fa sempre bene: qualche mese fa ho fatto un nuovo acquisto, ossia un All In One con monitor da 27 pollici e specifiche tecniche parecchio elevato, marchio ASUS, totalmente compatibile con Linux, e tremendo gaudio sia lavorativo che per quanto riguarda l’entertainment. Ci ho infatti sostituito persino il televisore, ormai rimasto alla mia famiglia meno digitalizzata (anche se, aehm, mia madre ne ha preso uno con ingresso USB poco dopo: devo aver inoculato il germe dell’USB anche in casa).

Bello eh, anzi: riesco a tenere aperte parecchie cose contemporaneamente, ma sento ancora la necessità di un secondo monitor, e – per quanto io stia provando a far entrare nel mio “studio” una scrivania più grande – le dimensioni sono quelle che sono, la metratura pure, e quindi per ora me la devo amabilmente prendere in quel posto; diversamente, con un solo monitor, sostenuto da una sola base, anche più grande, riuscirei comunque ad avere un diverso assetto con la scrivania che ho, mantenendo l’arredamento simile e avendo più spazio “digitale” (desktop! LOL) a disposizione.

Se debbo fare un appunto alla mia workstation infatti, è solo la densità di pixel “standard”. Questo (vista l’avanguardia generale della componentistica di cui parliamo), esattamente come per Hauer, genera in me un certo disappunto. Parecchio disappunto.

Questo mi serve, altro che 3D

Vabbeh, vedémoselo.

Più o meno questa è la reazione mia e dei miei amici, ogni volta che andiamo al cinema (chiaramente a Roma come avete percepito dall’accento) e ci viene proposto un film in 3D dove non è possibile scegliere l’alternativa in 2D. Chiaramente non è che io sia contro il 3D, che anzi al cinema è un’esperienza carina, ma tra lo spam dei cinematografi e la campagna d’assedio a cui ci ha sottoposto chi vende monitor e televisori, ne ho avuto veramente abbastanza di chi ha voluto veramente farci credere che la risoluzione non fosse più un fattore importante e discriminante nella scelta di un dispositivo di visualizzazione.

Così, quando per la prima volta ho visto un monitor 4K, e a maggior ragione quando ho letto il post in oggetto, ho pensato una sola cosa: “Avete finito di cercare di infinocchiarci, maledetti”. Semplicemente perché mentre della tecnologia di riproduzione 3D possiamo fare a meno in quanto inerente prettamente l’ambito della divertenza (che termine fico eh), l’ambito della definizione e della risoluzione è qualcosa dove, al confronto con un monitor – o meglio ancora un televisore – 4K, un dispositivo tradizionale mostra il fianco, e senza cotta di maglia.

Con lo spazio per 4 colonne di editor di testo aperte, svariati terminali con qualcosa in esecuzione dentro, e la possibilità di affiancare a tutto comunque un browser per visualizzare il risultato del nostro sviluppo web, o l’emulatore dell’SDK per chi sviluppa nel settore mobile (e così via…), le specifiche di qualsiasi cosa che non sia l’ultimo modello di Zenbook dove su un 13 pollici abbiamo una risoluzione di duemilacinquecento e rotti pixel in orizzontale, risultano tremendamente imbarazzanti. Ma che dico imbarazzanti, praticamente di un’era passata.

Risoluzione, definizione, monitor e fattori di forma (un sacco di roba quindi)

Da quel che so, il sesso non ha avuto aggiornamenti con grafica ad alta definizione e armamenti potenziati. – Sheldon Cooper

Dato che un televisore 4K al posto di un monitor mette in luce quanto l’industria degli schermi si sia adagiata sugli allori, e questo l’abbiamo già acclarato abbondantemente, azzardiamo anche qualche previsione su quello che succederà in questi anni di profonda rivoluzione nel campo desktop, a causa di qualcosa che finalmente serve alla massa e non ai proprietari dei cinema per venderti un biglietto da 10 (dieci) euro – o se preferite, a chi vuole venderti un 40 pollici che, al posto di fare il televisore, potrà fare tranquillamente da soprammobile. Con buona pace degli amanti del treddì.

  • Il porno: Naughty America ha annunciato proprio in questi giorni che sono i fase pianificazione i primi film pornografici girati in 4K. Modestamente, in quanto esperto dell’ambito (:D), ritengo che questo cambierà parecchi aspetti nell’ambito home video: dato che il VHS ha vinto contro il Betamax complice il porno, la spinta dell’industria pornografica se ingente ha le carte in regola per rendere 4K un successo, mentre il “good enough” 3D nell’ambito rimarrà al palo. E si sa, per chi rimane al palo nel mondo del porno butta male. Oddio, effettivamente dipende da quale palo.
  • L’imbarazzo dell’anzianità: qualche tempo fa ho avuto l’immenso piacere di provare il Dell XPS Developer Edition, che un mio coworker ha anche acquistato. Il lavoro su uno schermo a così alta risoluzione è comodissimo, e immagino che lavorare con un monitor 4K mi farebbe voglia di fiondare dalla finestra il mio All In One esattamente come dopo aver provato l’XPS  è stato terribilmente traumatizzante tornare al mio “legacy laptop” con il suo monitor, per così dire, stretto.
  • Le dimensioni contano: mettiamo caso che finalmente arrivi un monitor 4K ad un costo decente, come ipotizza anche Hauer; a questo punto, con abbastanza spazio per quattro colonne di editor di testo, svariate CLI aperte e uno o più browser, tornereste veramente ad una configurazione della scrivania con monitor multipli? Nonostante a me piaccia la configurazione multi-monitor e io sia dell’opinione che i pixel non sono mai troppi, i limiti fisici della mia scrivania mi impediscono sia di avere due monitor, al momento (ed è per questo che sto cambiando scrivania eh), ma anche se questa fosse più grande preferirei risparmiare spazio in favore di qualcos’altro. Insomma, in due parole: le nostre scrivanie, dopo l’avvento e la massificazione del 4K, non saranno più le stesse.

Quando vi tireranno fuori l’ennesimo pacco per farci accontentare della qualità d’immagine attuale, non date soddisfazione a nessuno. D’altronde, il regno del 4K sta per cominciare, ma l’8K si profila già all’orizzonte, e potrebbe darci ancora più soddisfazione.

Photo courtesy of Tutaka Tsutano

2014.start();

- Tech

Change

È stato un anno ricco di cose. Cose belle, cose brutte, non importa (oddio, per la gran parte comunque cose belle – e di questo mi compiaccio). Fatto sta, che l’altro ieri mi sono trovato a sedermi e, per la prima volta in un anno e forse più, ho potuto decidere di non fare nulla tutto il giorno. È stato un anno di cambiamento, per me e per tutti quelli che mi hanno circondato; spero, ovviamente, che il cambiamento sia stato positivo – soprattutto per me, che diavolo, ma anche per gli altri: il lavoro, quello che è stato prodotto da me e da chi mi circonda durante l’anno, è stato parecchio e proficuo. Bene così.

Ma il cambiamento va portato avanti fino alla fine: e così ho deciso di cambiare nome e veste persino a questo blog, che rinasce dalle proprie ceneri e diventa “Grab The Blaster“. Un po’ quello di prima, un po’ cose nuove, progetti nuovi, una vita nuova. È la prima volta che festeggio l’inizio di un anno così sentitamente: forse perché nel nuovo spero molto, ci ripongo parecchie speranze.

Solo una cosa rimane la stessa: la mia nerditudine. E un costante desiderio di debuggarmi la vita, per quanto arduo possa essere. Come ha detto un amico una volta, “life is a continuous pivoting”. Non mi resta che far partire il nuovo thread, e sperare che non incontri deadlock o race condition.

2014.start();

(Tra l’altro, postilla: il codice del tema sarà open source prestissimo. Il tempo di correggere un paio di cose fastidiose.)

Photo courtesy of Stéfan

Quel momento di sano sclero tecnologico

- Linux

Scream

Ma quanto sono demente da uno a venticinquemila? Venticinquemiladuecento, ovvio. È il momento sclero tecnologico. Perché è il momento sclero tecnologico? Ma perché l’ho deciso io, e l’ho deciso perché ho appena perso sedici ziliardi di ore lavorative appresso a qualcosa che, nel momento del salvataggio, ha deciso di andarsene bellamente in camporella invece che nel mio hard disk. Come lacrime nella pioggia.

Background: con tutto il set del mastro ferraio aperto decido di lanciarmi in un aggiornamento suicida del PC tanto – ehi – che male può fare? Ebbene, Yum (questo, dico, il package manager) mi avvisa che nonostante io stia lavorando alacremente, lui aggiornerà comunque tutto il desktop environment, sia perché lui è programmato così, sia perché effettivamente è disponibile una nuova versione e sia mai che io mi perda le novità. Gli dico tranquillamente di aggiornare, tanto – yeah, che male possono fare quei 500 mega di aggiornamenti ad un computer che non è tanto sotto stress hardware, quanto sotto stress del sottoscritto che sta riducendo la tastiera a una poltiglia per lavoro?

Ok, aggiorna, aggiorno, perfetto. È qualche ora dopo che, immemore del mio aggiornamento perché, diamine, è andato tutto liscio, decido di salvare quello che ho prodotto senza farmi alcuna copia di backup – e ovviamente ecco che BAM, il desktop comincia a fare le grinze e accartocciarsi, lasciandomi con un pugno di mosche.

La quiete prima della tempesta.

Poi un sano urlo.

Vedi Calcare? Quando sei così demente da lanciare aggiornamenti random sulla tua macchina, manco il “salva ogni cinque minuti” t’aiuta più.

Photo courtesy of Kenny Louie