Grab The Blaster di Alessio Biancalana

Kernel Linux - kdbus sta per entrare a gamba tesa nella mainline

Atomic Explosion

This is the first submission of kdbus by the kernel community. It was developed in its own repository for well more than a year, and has been tested on x64-64, i686 and ARM architectures in various use cases. The driver is totally non-intrusive and doesn't touch a single line of existing kernel code.

Forse il kernel Linux è arrivato ad una delle sue più grandi svolte (almeno secondo me): un primo abbozzo di kdbus è stato sottomesso alla Linux Kernel Mailing List (si, sottomesso come nel sadomaso, grazie a Giorgio per la segnalazione) per l'approvazione. Per chi non sapesse che cos'è kdbus, cito sempre dalla stessa mail:

kdbus is a kernel-level IPC implementation that aims for resemblance to the the protocol layer with the existing userspace D-Bus daemon while enabling some features that couldn't be implemented before in userspace.

Per avere la capacità di afferrare il cambiamento che sta per avvenire quindi dovete avere una nozione in testa più o meno consistente di:

In poche parole, se veramente la community riuscirà ad ottenere un'infrastruttura di IPC nel kernel, vari software potranno trarne vantaggio per un funzionamento migliore ed essenzialmente anche più veloce e snello (chi ha detto Systemd? O init, perché no?). Probabilmente, ora come ora, stiamo vivendo un momento storico per lo sviluppo del kernel Linux come lo conosciamo. Fate molta attenzione se vi interessa.

Photo courtesy of James Vaughan

Nexus 9 - impressioni preliminari

Nexus 9

E insomma, dice che il 15 ottobre (indiscrezione da confermare - anche se ormai facciamo prima a vedere se tra qualche giorno succede veramente) insieme al disco di debutto degli abstracts presentano anche il Nexus 9. HTC ha fatto veramente un gran lavoro stavolta, esattamente come (secondo me) fece col Nexus One, e se i rumor si confermassero veri avremmo gli elementi per parlare di un nuovo successone di Google e di Android su tablet. Quanto era già successo col Nexus 7, infatti, ovvero l'entrata a gamba tesa di Google in un mercato tutto nuovo ponendosi di fatto in maniera totalmente diversa da Apple - la quale puntava ad un dispositivo general purpose, mentre Asus insieme a Google ha dato maggior priorità a operazioni come la lettura, proponendo un fattore di forma decisamente piacevole in modalità portrait, praticamente ridicolo in modalità landscape - si ripeterà con Google che stavolta aggredisce un fattore di forma decisamente più consono ad un tablet, con un monitor più ampio e meno stretto.

Io voglio cambiare tablet, quindi ho cominciato a dare un'occhiata a quello che ci aspetta con questo piccolo grande gioiellino già qualche tempo fa.

Le caratteristiche

Facendo un piccolo riassunto, abbiamo di che essere contenti. Dentro questo "coso" che è il Nexus 9 infatti troveremo parecchie piccole sorprese:

  • CPU NVIDIA Tegra K1 (quella famosa nuova, a 64 bit, eccetera);
  • Svariati giga di RAM - mi pareva di aver letto 4GB ma sono sul treno, con la connessione che va e viene, quindi non posso controllare;
  • Risoluzione qHD, quindi 2560x1600, ovvero quello che qualsiasi monitor nel 2014 dovrebbe avere;
  • Un prezzo fuori dal normale, nel senso che a conti fatti costerà meno di quanto mi aspettassi.

Oltre questo, sono state diffuse anche foto di una cover fichissima, in grado di rivaleggiare probabilmente con quella di iPad per la quale ho sempre provato un po' di invidia, dato che comunque poter mettere il tablet "dritto" fa sempre comodo. E non ci provate: le altre cover in commercio sono una schifezza. :-D

Potrebbe essere la svolta

Il Nexus 7 2013 era stretto come il Nexus 7 2012. E il Nexus 7 2012 faceva cagare in ogni senso. Lo so, mi spiace, è stato un bel dispositivo che mi ha accompagnato fedelmente, ma diciamo le cose come stanno: chi ha pensato l'hardware e la build di Android che è andata su quell'affare ha fatto decisamente un pessimo lavoro, dato che installando package di una dimensione considerevole il tablet diventa lentissimo per un difetto nella memoria (che il trim automatico allevia ma non risolve). Questo Nexus 9 potrebbe dare nuova linfa al mercato dei tablet Android.

Se infatti le piattaforme concorrenti (in particolare una) hanno maturato un ecosistema di applicazioni consistente, Android su tablet sembra non voler prendere il volo in tempo per darci un'esperienza utente completa e consistente quanto quella su (dico a caso eh) iPad entro un anno da ora. Il Nexus 9 potrebbe essere un ulteriore trampolino di lancio per stimolare gli sviluppatori a produrre materiale edibile per i tablet che sia possibilmente autoconsistente e con una user experience dedicata, definita e nel complesso buona.

Dicevamo, il prezzo

Girano delle indiscrezioni nell'Internet secondo le quali troveremo il Nexus 9 di Google sugli scaffali (avete capito bene: non solo Play Store a quanto pare - ma io penso di prenderlo da lì ugualmente) a 399 dollari. Il che significa 400 euro in Italia, eccezion fatta per ulteriori maggiorazioni che non dovrebbero avvenire: per un tablet così, con queste caratteristiche, questo form factor e soprattutto Android L fresco fresco, direi che l'acquisto vale la pena e vale la spesa. Soprattutto se siete possessori come me di un Nexus 7 2012 che potreste fiondare in qualsiasi momento dalla finestra.

Il piano di battaglia? Il 15 ottobre pare ci debba essere l'annuncio, il 3 novembre la disponibilità. E io entro il 15 novembre avrò sicuramente il corriere che si accanisce sul citofono dell'ufficio. :-D

I sistemi operativi e l'eredità degli antichi

Un urlo per i sistemi operativi, ragazzi

Abbiamo un problema. E il nostro problema è che usiamo dei sistemi operativi sostanzialmente, globalmente, inaffidabili. Ora, ci sono vari gradi di inaffidabilità: quello di cui sto parlando io adesso riguarda l'eredità degli antichi insita nei nostri sistemi, ovvero il fatto che per fare le cose più in fretta chi ha partorito gli aborti tecnologici che abbiamo ogni giorno sotto al sedere ha deciso di integrare dei prodotti già esistenti per formarne uno nuovo. Ogni sistema operativo è fatto così, è la somma di più software in parte preesistenti al sistema stesso; proprio in questi giorni abbiamo assistito alla messa a nudo di una falla gravissima nella Bash, la shell che generalmente usiamo sui nostri sistemi Linux o sui nostri Mac. E ancora prima abbiamo guardato impotenti (o circa) cadere ogni sistema basato su OpenSSL "grazie" ad Heartbleed. Nel caso specifico di Bash, però c'è stato qualcosa che in molti hanno esternato, ovvero:

Ma possibile che ci siamo accorti di questa cosa solo vent'anni dopo che questo baco è stato mandato in giro?

Durante questo weekend, mi sono fatto un'opinione precisa della sicurezza informatica. E questa opinione, altamente negativa, è stata alimentata anche da uno scritto che ho letto su un paste selvatico in rete, il cui link potete trovare in calce al post, di cui riporto una parte:

The problem is that it was designed 25 years ago. Apache didn't exist yet for five years! Granted, the internet already existed, but it was still a more confidential club. Security in internet software and protocols were often just not considered at all in that time, and definitely not when developping a program such as a shell. [...] The problem is that 5 years later, new software was developed (apache, dhcp, etc), that uses bash in child processes, and which still uses environment variables to pass data. Unfortunately, some of that data comes not from the trusted user of the local system, but comes from random users and program on the other side of the internet and of the planet. And in the meantime, the undocumented (and under-published) feature of bash is forgotten.

La verità è che siamo fottuti. :-)

Basiamo i nostri sistemi operativi su uno strato di software concepito anni, anni, e anni fa senza preoccuparci minimamente che questi vengano riscritti per essere adattati a come oggi funzionano le tecnologie, a come oggi i sistemi comunicano tra di loro. Allo stesso modo, il mercato delle falle 0day fiorisce per il semplice fatto che parecchi smanettoni non sanno tenere le mani a posto (e meno male, vah), quindi ogni tanto fanno un danno serio che fa drizzare le orecchie a chi di dovere. Ne abbiamo ancora di robaccia da spalar via, quindi mi limito a constatare questo, a farlo presente ancora una volta, e soprattutto ad allegare qui di seguito la lista di articoli che mi ha fatto rendere conto di come, in realtà, ogni pezzo di software in circolazione sia irrimediabilmente compromesso per ragioni sue o di altri software che lo chiamano, lo sballottano, lo trattano in maniera stramba.

Siamo specialisti dell'IT, la nostra è una missione. Ma dopo aver letto uno dopo l'altro questi quattro articoli, vi assicuro che ho guardato con molta cupidigia la zappa che ho in cantina.

Scommetto che al raccolto avrò dei fiori di zucca bellissimi.

Photo courtesy of Luca Rossato

Jekyll e GitHub Pages, come impostare correttamente il proprio dominio

Io.

Guardate questo volto. È il mio, ed è il volto di un uomo distrutto durante un weekend in cui pur avendo degli impegni ha fatto nottata a migrare il blog ad un nuovo CMS. In realtà la questione è un po' meno semplice di così, e mi serve per introdurre un argomento importante per chi ha intenzione di migrare il proprio sito a Jekyll mantenendo inalterata la funzionalità globale (compresa soprattutto quella social).

Cominciamo dal principio: poco prima della Blogfest (quest'anno Festa della Rete) ho migrato il mio blog a Jekyll, dopodiché tutto contentone ho sfornato un post con alcuni consigli, mantenendo comunque nel mio product backlog (volendo usare termini da fuffarolo Agile) la reintroduzione dei commenti e delle funzionalità legate alla Graph API di Facebook: solo durante il weekend mi sono reso conto che proprio da quel punto di vista avevo spaccato tutto. A Facebook infatti non piace per niente l'impostazione dei record A consigliata da GitHub, quindi se usate GitHub Pages per servire le vostre pagine e volete che l'entity debugger vi sorrida, dovete per prima cosa utilizzare un CNAME per la root del vostro dominio. Ovviamente io sono fortunatissimo... e quindi OVH non supporta tutto questo.

Ora, quello che accade è che possiamo trovarci davanti a due eventalità pessime: la prima è quella che è successa a me, ovvero che il provider non fornisca nessuno strumento per assegnare un CNAME al proprio dominio; la seconda è quasi peggiore, ovvero che il provider da cui abbiamo registrato il dominio fornisca si una maniera anche agevole per assegnare all'apex domain un CNAME, ma gestisca molto molto molto male la cosa.

Prima di buttarmi in un angolo con della birra a fare l'alcolista, ho greppato l'internet per un po' e in preda alla disperazione più totale CloudFlare si è presentato a me come un servizio circonfuso di luce. Tramite CloudFlare infatti non solo possiamo avvalerci di una CDN notevole, ma possiamo anche (chiaramente) scegliere di non curarci di questo e abilitare solo le caratteristiche di base, gratuitamente, che ci permettono di gestire il DNS del nostro dominio supportando tutto quello che manca invece al nostro provider di servizi.

Se vogliamo quindi ospitare il nostro sito su GitHub Pages, ci basterà iscriverci a CloudFlare e invece che inserire un record A puntare un CNAME dal nostro dominio al nostro sottodominio di GitHub (nel mio caso, dottorblaster.github.io). Successivamente - e questa è la parte peggiore - dobbiamo togliere la delegazione dei DNS al nostro provider e dobbiamo impostare i DNS di CloudFlare per il nostro dominio. Questo può essere fatto direttamente da qualsiasi pannello di controllo, ma da quando l'avremo fatto ci vorranno dalle ventiquattro alle settantadue ore perché le modifiche abbiano effetto. Per quanto riguarda questo passo ho avuto un'esperienza terribile perché per circa una ventina di ore i DNS hanno continuato a sfarfallare tra il vecchio e il nuovo dominio, causando anche dei malfunzionamenti a tutto il cucuzzaro.

Una volta fatto tutto e atteso quanto dovuto, apriamo un terminale e verifichiamo che tutto stia funzionando a dovere:

blaster@boromir ~ $ dig dottorblaster.it

; <<>> DiG 9.8.3-P1 <<>> dottorblaster.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12044
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dottorblaster.it.      IN  A

;; ANSWER SECTION:
dottorblaster.it.   239 IN  A   104.28.3.118
dottorblaster.it.   239 IN  A   104.28.2.118

;; Query time: 5379 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep 18 14:07:04 2014
;; MSG SIZE  rcvd: 66

Ora che il vostro CNAME record sul dominio "nudo" non rompe l'Internet, leggetevi una comoda spiegazione dell'implementazione di questa feature da parte di CloudFlare, totalmente RFC-compliant. Perché ho scritto tutto questo? Perché se avessi saputo tutte queste cose in anticipo, probabilmente Angelo, che mi ha scattato quella foto, avrebbe avuto non dico un soggetto migliore, ma quantomeno un soggetto meno sfatto, con gli occhi meno pesti.

Photo courtesy of Angelo Ghigi

OS X, ottenere una lista dei processi in ascolto da terminale

lsof OSX

A volte su OS X di Apple ci aspettiamo che la command line sia uguale a quella che abbiamo su Linux, ma non è decisamente il caso. Per esempio, uno dei casi lampanti è il voler verificare le porte aperte e i processi in ascolto sulle porte: mentre su Linux potremmo sbrogliarcela decisamente bene usando netstat, su un Mac siamo costretti a usare lsof, che è una utility piuttosto carina.

Mi appunto qui il comando per non perdermelo ancora (ché tanto poi c'è San Google):

$ lsof -i | grep LISTEN | grep "TCP \*:" | sort

Se poi vogliamo buttare un occhio a quali processi hanno una connessione aperta (stabilita), allora possiamo utilizzare quest'altro comando:

$ lsof -i | grep ESTABLISHED | sort

Take care :-) Personalmente, non vedo l'ora di tornare a Linux, ma al momento sono costretto ad un Mac. Non è manco malaccio ma... volete mettere?

Image courtesy of Simon Ganiere