La nuova dock a comparsa e le gestualità del touchpad configurabili su Chrome OS hanno raccolto l’approvazione di Torvalds che non ha perso l’occasione di criticare le scelte degli sviluppatori di GNOME 3: le stesse caratteristiche sono state rimosse dal desktop environment. Infatti, erano considerate confusionarie e poco sfruttate.

Torvalds pensa che il nuovo approccio di Aura possa funzionare. Si riferisce, in particolare, alla possibilità d’avviare le applicazioni a tutto schermo anziché in una finestra del browser. Quest’ultima caratteristica è piuttosto simile ai programmi predefiniti adottati da GNOME 3.4, però Torvalds non accenna a salvare GNOME Shell.

Via | Google+

L’infrastruttura del mirror è la stessa che mantiene i sorgenti di Android: un network diviso tra Asia, Europa e Stati Uniti per garantire la massima velocità possibile in download. Il kernel di Linux, com’è risaputo, utilizza Git e Google Code aveva aggiunto il supporto al DVCS – insieme a Subversion e Mercurial – lo scorso luglio.

Perché Google dovrebbe offrire un mirror di kernel.org? Forse, Mountain View non si fida abbastanza del nuovo dominio di Linux e, per tutelare i distributori di Android, preferisce assicurarsi che il kernel sia accessibile, in caso di nuovi attacchi. Nel frattempo, kernel.org è stato completamente ridisegnato col supporto ad HTTPS.

Via | Google

Gli utenti che avessero ancora una copia di Picasa per Linux potranno continuare a utilizzarla, consapevoli del fatto che Google non proporrà più degli aggiornamenti. Proprio a causa delle sue caratteristiche, Picasa per Linux non è decollato — altri programmi (F-Spot, Shotwell, ecc.) interagiscono nativamente con Picasa Web Albums.

L’ultima versione di Picasa, piuttosto, è orientata a Google+. Le raccolte di Picasa Web Albums e quelle del social network di Mountain View sono soltanto dei mirror delle stesse fotografie: Android può sfruttare l’uploader di Google+, mentre Chrome OS può avvalersi dell’interfaccia web. Insomma, nessuno rimpiange Picasa per Linux.

Via | Google

Google ha iniziato la distribuzione di mod_spdy, il modulo per attivare il protocollo SPDY sui web server equipaggiati con Apache. Una novità importante per la diffusione del progetto, già attivo su Chrom* e previsto col prossimo rilascio su Firefox. Il video mostra una sorta di benchmark nei confronti di HTTPS, ma non è esaustivo.

Implementare SPDY sul proprio server è relativamente semplice, ma perché arrivi su tutti i servizi di hosting ci vorrà del tempo: mod_spdy richiede sia Secure Sockets Layer (SSL), sia Transport Layer Security (TLS) e perciò è legato all’acquisto d’un certificato sul proprio dominio — mod_spdy include una propria versione di mod_ssl.

Installato su Apache 2.2.x, dai sorgenti o dai pacchetti .DEB ed .RPM, mod_spdy funziona esclusivamente coi browser compatibili e sul protocollo HTTPS. Ad oggi, significa soltanto Chrom*. È un investimento sul futuro: Twitter è stato tra i primi a scommettere su SPDY. Quanto possa davvero servire a blog e siti web… è da dimostrare.

Via | Google

Rilasciato sotto una licenza compatibile con la BSD, Go è stato concepito da Ken Thompson, Rob Pike e Robert Griesemer: soltanto nel novembre del 2009 è arrivata l’ufficializzazione del linguaggio. Google ha concentrato le proprie risorse su DART, una soluzione alternativa a JavaScript per HTML5, e di Go non s’è più saputo granché.

Almeno, fino a ieri. Google s’appresta a distribuire il Software Development Kit (SDK) di Go per l’uso con AppEngine e la release candidate determina il feature-freezing del linguaggio. Le prossime settimane saranno dedicate alla soluzione dei problemi e sarà distribuita la prima versione. Farà più in fretta Go 1.0 o The GIMP 2.8?

Via | The H Open

Prescindendo dall’esclusione di Windows, abbastanza prevedibile, i binari di Dartium per Linux sono compilati su Ubuntu/Lucid – la Long Term Support (LTS) di Canonical – a 64-bit. Una scelta poco comprensibile: Google sconsiglia d’utilizzare Dartium come il browser predefinito perché non pregiudichi un’altra installazione di Chrom*.

Comunque, i sorgenti di Dartium sono compatibili con qualunque distribuzione e su Mac OS X il problema non sembra porsi neppure coi binari. Rispetto all’enfasi posta da Google su DART, la cura dei dettagli di questo browser lascia a desiderare: forse, lo sviluppo è più indietro di quanto gli ingegneri di Mountain View prevedessero.

Via | Chromium

Tutti gli altri browser, invece, visualizzano soltanto gli esempi preimpostati da Google: una raccolta ispirata alle funzioni più comuni di JavaScript e jQuery. DART è ispirato proprio da quest’ultimo per la verifica del supporto al linguaggio, in sostituzione al markup di noscript. È un punto di partenza pensato per i web designer.

Rispetto a Go, il linguaggio integrato in GCC con la versione 4.6, Google dedica più spazio a DART. Appena un paio di settimane fa è stato realizzato un porting di Box2D — l’engine di Angry Birds. Dart Synonym è un altro strumento per attrarre l’attenzione degli sviluppatori: il nome in codice, molto suggestivo, è Stele di Rosetta.

Via | Chromium

Il progetto risultante è Stardroid, al momento ospitato su Google Code: la scelta della licenza Apache 2.0 lascia pensare che, in futuro, anche Sky Map potrebbe essere consegnata a Incubator. Prescindendo dall’utilità o meno di disporre dei sorgenti di Sky Map, l’atteggiamento di Google è particolarmente deprecabile per vari motivi.

Mentre apriva i sorgenti di Sky Map alla comunità, Google disponeva la chiusura del popolare servizio di modifica delle fotografie. Se a Mountain View tenessero davvero all’open source avrebbero “liberato” pure i sorgenti di Picnik. Poiché si tratta d’una soluzione di successo, invece, hanno soltanto integrato il codice in Google+.

Via | Google Research

Nello specifico, WebRTC – l’acronimo per Real-Time Communication – è la tecnologia sviluppata da Google su Hangouts, la funzione di videoconferenza in Google+. Mountain View ha sottoposto l’architettura alla valutazione di W3C e IETF perché WebRTC possa diventare uno standard. Il supporto “nativo” su Chrom* è un vantaggio per Linux.

Ad esempio, l’adozione di WebRTC renderà facoltativo il plugin di GTalk per il supporto a voce e video. La libreria è disponibile per Linux a 32-bit e 64-bit, ma soltanto pre-compilata nei pacchetti DEB ed RPM. WebRTC, al contrario, è più simile a Jingle: la tecnologia di XMPP per VoIP e videoconferenze. È una soluzione più duttile.

Se non intendete aggiornare Chromium compilandone i sorgenti o la distribuzione in uso non ne prevede i pacchetti, il supporto di WebRTC può essere ottenuto facilmente da Chrome Dev – la versione “brandizzata” di Google – su qualunque sistema operativo. Scaricato e installato il browser, bisogna lanciarlo con --enable-media-stream.

Prima di generare false aspettative, è bene sottolineare che per il momento WebRTC su Chrom* non serve praticamente a nulla. GTalk tuttora non l’ha adottato, perciò il plugin che ho citato rimane necessario per le videoconferenze. Hangouts di Google+, invece, implementa WebRTC lato-server — e il supporto del browser non è richiesto.

L’unica ragione per attivare WebRTC su Chrom* è lo sviluppo di applicazioni basate sul framework di Google. In particolare, è utile a chi volesse ospitare la propria soluzione su AppEngine: è stata redatta una breve documentazione per l’avvio del programma d’esempio. Agli utenti, invece, è sufficiente un browser che supporti HTML5.

Via | WebRTC

Le patch sono pronte a essere inserite nei sorgenti del kernel e probabilmente faranno parte di Linux 3.3. Ad oggi, Btrfs permette di scegliere tra GZip ed LZO effettuando il montaggio del file system col flag compress attivato. LZO è la scelta predefinita, se non si opta per specificare un algoritmo. Snappy è open source dal 2011.

Kleen ha riscritto il codice di Snappy, originariamente in C++, in C perché fosse più adatto al kernel di Linux. Il livello di compressione non dovrebbe scostarsi granché da quello di LZO, ma Snappy parrebbe essere più veloce coi processori a 64-bit oppure Intel Atom a 32-bit. È un aspetto ancora da verificare nell’uso quotidiano.

Via | Phoronix

Il videogioco di Rovio non è open source e quand’anche la società decidesse, accordandosi con Google, di distribuire Angry Birds in DART sul Chrome Web Store… i benefit per gli sviluppatori sarebbero nulli. Non sarebbe comunque possibile, ad esempio, generare dei livelli aggiuntivi. Quello di Google sembra poco più d’un virtuosismo.

La stessa Google ammette, in parte, questa tesi. L’intenzione della società è dimostrare la possibilità di creare dei videogiochi in DART: Box2D non è popolare quanto Angry Birds, ma quest’ultimo non potrebbe esistere senza — e i programmatori lo sanno. Tuttavia, DART sembra condividere il destino di Go. Resterà pressoché ignorato?

Via | Google Open Source

Oltre a fornire i sorgenti, Google ha inserito Video Player Sample sul Web Store per sfruttarne immediatamente le caratteristiche. Con qualunque browser supporti HTML5 è possibile provarne una demo: non è obbligatorio il browser di Google. Il vantaggio nell’utilizzo di Chrom* è la possibilità d’avvalersi delle notifiche sul desktop.

Personalizzare Video Player Sample è semplicissimo e, in ogni caso, può essere un ottimo punto di partenza — per creare delle applicazioni più complesse. Il codice è stato compilato coi Closure Tools di Google: l’archivio del programma include sia i binari, sia i sorgenti da compilare. Può essere utile consultare la documentazione.

Via | Google Open Source

L’idea di utilizzare l’account registrato per usufruire d’un servizio web come login sul proprio computer è stata introdotta da Google coi Chromebook ed emulata da Microsoft per Windows 8. Entrambe le soluzioni sono limitate al sistema operativo d’appartenenza: Google pensa d’estendere il supporto del SSO anche a Mac OS X e Windows.

Si parla d’avere un unico login, con una sola password, per accedere alla maggioranza dei servizi necessari alle operazioni più comuni. Un’evoluzione del cloud computing applicato al sistema operativo: quest’ultimo non avrà più alcuna importanza. Per Linux, ecc. è una grande opportunità. Tuttavia, implica molti problemi di privacy.

Una soluzione del genere sottintende l’esposizione a Google di qualunque dato presente sul proprio sistema e per quanto i vantaggi possano essere appetibili il controllo totale della privacy diventerebbe un lavoro immane. In compenso, associato a Google Apps, il SSO potrebbe agevolare l’interazione remota con aziende e istituzioni.

Se Google adottasse la comune strategia di rilascio anche per questo progetto, esisterebbe comunque una versione open source che – più di Chromium OS – potrebbe attrarre l’interesse di molti soggetti. Ad esempio, quella di Canonical: immaginate il SSO di Ubuntu attivo già dall’installazione del sistema che interagisce con Launchpad.

Canonical è, forse, la società attiva nell’open source che potrebbe beneficiare maggiormente d’una simile iniziativa di Google. Ubuntu One è disponibile su vari sistemi e l’indirizzo della distribuzione segue la falsariga dell’idea di Google per il SSO: una certa indipendenza dalla piattaforma. Bisogna attendere la mossa di Google.

Via | ZDNet

Come sempre, nelle analisi la raccolta dei dati è un’attività oggettiva, il problema poi rimane la metrica utilizzata. Infatti, i ricercatori Accuvant hanno deciso che per valutare la sicurezza dei browser i fattori discriminanti non sono la presenza, il numero o la gravità delle falle (ad esempio buffer overflow), ma piuttosto le azioni intraprese per limitare i danni al momento dell’attacco.

L’oggetto dello studio è quindi il comportamento di default in presenza di exploit. Di conseguenza tutta l’analisi ignora completamente la “responsività” del team di sviluppo nel rilascio di soluzioni efficaci. Il test, effettuato su Windows 7, ha dato i seguenti risultati: primo Google Chrome, secondo Internet Explorer e terzo Mozilla Firefox. Fa un certo effetto vedere Internet Explorer al secondo posto.

L’immagine che ne viene fuori è una sostanziale inadeguatezza delle tecnologie di Firefox. Di fatto è rimasto l’unico a non implementare una sandbox degna. Probabilmente un altro segno dei tempi che cambiano. Purtroppo. Ne avevamo avuto già un assaggio quando la vulnerabilità dei protocolli SSL-TLS stava imperversando e mieteva terrore ovunque. Gli ingegneri Mozilla elaborarono un piano tanto geniale quanto lungimirante: disabilitare Java. L’efficacia è ineccepibile.

Dall’altra parte invece, sviluppatori Google stavano approntando una soluzione non definitiva ma che rendeva il traffico catturato più “randomico” e quindi meno comprensibile all’attaccante. Il tutto senza scatenare discussioni religiose nel loro bugzilla. Probabilmente rilasciare versioni ogni sei settimane non basta a colmare il divario.

EDIT: riportiamo la dichiarazione di Johnathan Nightingale, Director of Firefox Engineering:

Firefox includes a broad array of technologies to eliminate or reduce security threats, from platform level features like address space randomization to internal systems like our layout frame poisoning system. Sandboxing is a useful addition to that toolbox that we are investigating, but no technology is a silver bullet. We invest in security throughout the development process with internal and external code reviews, constant testing and analysis of running code, and rapid response to security issues when they emerge. We’re proud of our reputation on security, and it remains a central priority for Firefox

Via | TheRegister

Il Kindle Fire di Amazon, il Nook di Barnes & Noble e il TouchPad di HP venduto con webOS sono alcuni prodotti che potranno accedere ad Android Market. L’utilizzo di quest’ultimo, però, è limitato all’interfaccia web: non sarà ancora distribuito come applicazione. Purtroppo nessuno di essi al momento è presente sul mercato italiano.

Il dato importante a mio avviso riguarda piuttosto la nuova politica di Google. Un altro piccolo sforzo e la società potrebbe accettare tutti i dispositivi su Android Market, magari fornendone l’applicazione. Il proliferare di schede integrate, ecc. che installano Android porterebbe ulteriori vantaggi economici alla multinazionale.

Via | Ubergizmo