SPDY Indicator è una nuova estensione di Chrom* che visualizza, con un’icona nella barra degli indirizzi del browser, il supporto dell’omonimo protocollo di Google. Concepita da Guillermo Rauch, è rilasciata sotto licenza MIT su GitHub. SPDY (lett. “speedy”) è la soluzione di Mountain View per sostituire il protocollo HTTP sul web.

Adottato da tutti i siti di Google, SPDY è previsto da Chrom* e – a partire dalla versione 11 – è stato integrato in Firefox. Recentemente, il protocollo ha raggiunto anche Twitter. Sebbene la percentuale dei server che lo utilizzano sia tuttora esigua, sono in aumento i provider che lo offrono come opzione per i servizi di hosting.

Chrome SPDY Indicator offre una soluzione semplice ed efficace per verificare l’effettivo supporto del protocollo. SPDY richiede esplicitamente l’utilizzo di HTTPS, perciò l’icona dell’estensione può “colorarsi” soltanto in presenza di connessioni SSL o TLS. La maggiore rapidità di SPDY rispetto ad HTTP sarebbe un discorso a parte.

Via | Guillermo Rauch

Chrome SPDY Indicator visualizza il supporto al protocollo di Google é stato pubblicato su Ossblog.it alle 11:00 di lunedì 12 marzo 2012.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Adobe ha annunciato qualche ora fa una decisione molto discutibile: Flash Player, il popolare plugin per il browser, sarà disponibile soltanto con Chrome — almeno, su Linux a 32-bit e a 64-bit. È il risultato d’una partnership stretta con Google. Il plugin utilizzerà Pepper Plugin API (PPAPI): altri browser potrebbero beneficiarne.

Il download diretto di Flash Player dai server di Adobe non sarà più possibile per Linux, mentre gli altri sistemi operativi non risentiranno della novità. La società sostiene che sarà distribuita una versione di debug del plugin affinché sia possibile valutare l’integrazione su altri browser, però non è ancora stato deciso il come.

PPAPI può essere potenzialmente implementato su tutti i browser, ma costituisce un sostituto delle Netscape Plugin API (NPAPI) di Firefox e – in futuro – sarà legato al Native Client (NaCl) di Chrom*. Per utilizzare Flash Player serviranno entrambi e, comunque, gli sviluppatori dovranno passare da Google per il supporto del plugin.

Aggiornamento: corretto il refuso nel titolo.

Via | Adobe

Sorpresa, Adobe distribuirà Flash per Linux soltanto su Google Chrome é stato pubblicato su Ossblog.it alle 14:00 di mercoledì 22 febbraio 2012.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Adobe ha annunciato qualche ora fa una decisione molto discutibile: Flash Player, il popolare plugin per il browser, sarà disponibile soltanto con Chrome — almeno, su Linux a 32-bit e a 64-bit. È il risultato d’una partnership stretta con Google. Il plugin utilizzerà Pepper Plugin API (PPAPI): altri browser potrebbero beneficiarne.

Il download diretto di Flash Player dai server di Adobe non sarà più possibile per Linux, mentre gli altri sistemi operativi non risentiranno della novità. La società sostiene che sarà distribuita una versione di debug del plugin affinché sia possibile valutare l’integrazione su altri browser, però non è ancora stato deciso il come.

PPAPI può essere potenzialmente implementato su tutti i browser, ma costituisce un sostituto delle Netscape Plugin API (NPAPI) di Firefox e – in futuro – sarà legato al Native Client (NaCl) di Chrom*. Per utilizzare Flash Player serviranno entrambi e, comunque, gli sviluppatori dovranno passare da Google per il supporto del plugin.

Via | Adobe

Sopresa, Adobe distribuirà Flash per Linux soltanto su Google Chrome é stato pubblicato su Ossblog.it alle 14:00 di mercoledì 22 febbraio 2012.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Chrom* Dev, il canale di sviluppo del browser di Google, ha appena acquisito il supporto a WebRTC per tutti i sistemi operativi. Quest’ultimo è un framework open source per la comunicazione in tempo reale da JavaScript su HTML5: non adotta una licenza approvata dalla Open Source Initiative (OSI). Il codice può essere ridistribuito.

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

Chrom* Dev ha acquisito il supporto a WebRTC, il framework di Google é stato pubblicato su Ossblog.it alle 09:00 di giovedì 19 gennaio 2012.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Miguel De Icaza ha presentato le novità di Moonlight 4, l’aggiornamento di Silverlight per Linux: iniziato a metà di febbraio, lo sviluppo riprende quelle funzionalità incluse in Moonlight 3 e aggiunge un nuovo framework per il rendering. Moonlight 4 supporta l’accelerazione hardware e riduce i passaggi per l’esecuzione dei comandi.

In pratica, anziché riconvertire il formato YUV in RGB, Moonlight 4 lo trasferisce direttamente alla GPU: il risultato è uno snellimento del processo di conversione che si traduce in una riduzione dei tempi d’esecuzione. Moonlight 4 non è ancora stato pubblicato, però si può già provare dalle nightly build o compilare dai sorgenti.

Indubbiamente, la Rich Internet Application (RIA) di Microsoft dovrebbe essere abbandonata in favore di HTML5: la stessa multinazionale ha dei piani differenti dal web per Silverlight. Tuttavia, è positivo che il porting su Linux stia piano piano raggiungendo la stessa maturità, con l’accelerazione hardware, del plugin per Windows.

Via | Miguel De Icaza

L accelerazione hardware di David Reveman è approdata su Moonlight 4 é stato pubblicato su ossblog alle 09:00 di venerdì 25 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Google ha presentato la versione stabile di Chrome 10 che promette un miglioramento delle prestazione fino al 66% rispetto a Chrome 9 in alcuni test.

Sono state semplificate anche le impostazioni del browser che ora sono un tab vero e proprio con tanto di motore interno di ricerca per non perdere tempo nella ricerca di una specifica impostazione. Nel video qui sopra potete vedere un esempio del nuovo comportamento.

Migliorata anche la funzionalità di sandboxing che consente di isolare del possibile codice malevolo. Ora anche il plugin flash gira all’interno di una sandbox per una maggior sicurezza. Sempre legato a flash c’è un aumento delle prestazioni dell’80% grazie all’abilitazione dell’accelerazione hardware. Se invece utilizzate Chromium oltre a queste novità aspettate anche di trovare un nuovo logo che assomiglia alla versione originale nel design e nei colori, ma ora è molto meno 3D.

Via | GoogleBlog

Google Chrome 10 é stato pubblicato su ossblog alle 16:59 di mercoledì 09 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Il progetto di Mozilla per realizzare un app store portabile sul web è diventata realtà: settimana scorsa è apparso un portale per le applicazioni dedicate a Firefox e Chrome. Sì, perché Firefox non è l’unico browser cui è orientato il progetto dei Mozilla Labs: altre piattaforme potrebbero arrivare presto, grazie agli sviluppatori.

Il supporto alle estensioni correntemente previste per Google Chrome non è l’unica caratteristica notevole del progetto. Mozilla ha concepito Web Applications per essere integrato su tutti i dispositivi desktop e mobile esistenti. Inoltre l’obiettivo include la possibilità di creare degli app store da installare sul proprio server.

Non tutte le funzionalità previste sono già state pubblicate: ad esempio, non è ancora possibile sincronizzare le applicazioni installate con un dispositivo portatile. Web Applications è in una fase estremamente sperimentale, benché si possano installare alcune delle applicazioni per il browser pubblicate in una directory pubblica.

Via | Mozilla Labs

Mozilla ha rilasciato la prima milestone del Web Application Project é stato pubblicato su ossblog alle 11:00 di lunedì 07 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

WebP è il nuovo formato per le immagini digitali proposto da Google in alternativa a JPEG. È mantenuto dal consorzio di WebM/VP8 e al momento è supportato soltanto da Chrome 9 o, superiore. Google ha aggiornato gli strumenti di conversione per Linux, OS X e Windows a 32-bit, a 64-bit e ha introdotto pure un componente per Microsoft.

Quest’ultimo dovrebbe abilitare il supporto a WebP nelle principali applicazioni per Windows, un passo fondamentale perché il formato possa prendere davvero piede. Gli strumenti a riga di comando per Linux e OS X equivalgono, in linea di massima, a quelli previsti per WebM. A differenza di VP8, WebP non sembra raccogliere consensi.

Convertire le immagini da JPEG a WebP è ormai relativamente semplice su tutti i principali sistemi operativi. Le immagini risultati pesano, sembra, il 39% in meno. WebP è uno dei progetti di Google per rendere il web più veloce: se così sarà, riguarderà soltanto Chrome. Almeno, finché gli altri produttori continueranno a ignorarlo.

Via | Libre Graphics World

Google aggiorna l econder di WebP, il formato delle immagini sul web é stato pubblicato su ossblog alle 09:00 di lunedì 28 febbraio 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Splashtop OS è un sistema operativo per laptop e netbook basato su Chromium e MeeGo. Se rimane incerto il futuro di MeeGo con la partnership tra Microsoft e Nokia su Windows Phone 7, questo “fork” è immediatamente disponibile. Splashtop OS sostituisce MeeGo a Ubuntu in un progetto del tutto simile a Jolicloud. S’installa da Windows.

Presentato al MWC 2011, Splashtop OS è il più ambizioso di tre progetti: Splashtop Remote permette di visualizzare il desktop su tablet, netbook e smartphone, mentre Splashtop Connect è un’estensione per Mozilla Firefox e Google Chrome (disponibile soltanto per Windows). Perciò la definizione di fork, rispetto a MeeGo, è impropria.

Il progetto è stato realizzato da Splashtop per fornire ai distributori OEM del proprio hardware un’alternativa a Windows 7, ritenuto troppo pesante, e Windows Phone 7, troppo limitato. Integra Intel AppUp e può diventare intrigante per lo sviluppo: non è un prodotto open source e non intende essere un’alternativa a MeeGo di Intel.

Via | Phoronix

Splashtop OS, un sistema operativo mobile basato su Chromium e MeeGo é stato pubblicato su ossblog alle 09:00 di giovedì 17 febbraio 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Evan Martin è uno sviluppatore di Google che lavora sul progetto Chrome che è composto da circa 30.000 file.

Con questi numeri ssando make per la compilazione possono essere necessari parecchi secondi fra l’esecuzione del comando e l’effettivo inizio della compilazione. Situazione ancora più tragica con altri tool come scons che sono sviluppati per rimpiazzare make.

Ritenendo insoddisfacente questa situazione ed innervosito dalla necessità di attendere troppo fra una modifica e l’effettiva compilazione ha deciso di rimboccarsi le maniche per produrre qualcosa di più efficiente a cui ha dato nome Ninja.

Ninja è in grado di arrivare, sui sorgenti di chrome, a far partire la compilazione entro un secondo dall’esecuzione del programma. Ninja analizza una serie di file per determinare il grado delle dipendenze e poi esegue i comandi necessari per la compilazione. All’interno del build file (build.ninja) sono presenti le regole e le indicazioni di come lanciare il compilatore.

Lo scopo di Ninja è di essere molto veloce e quindi non ci sono regole implicite. Tutto viene specificato in maniera esplicita ed è per questo motivo che è preferibile utilizzare un generatore per i build file. È proprio grazie a questa filosofia che il progetto riesce ad essere molto veloce.

Fra i progetti futuri è anche interessante l’integrazione con inotify per mantenere i sorgenti sempre compilati.

Via | Github

Ninja, un altro rimpiazzo per make é stato pubblicato su ossblog alle 10:00 di mercoledì 09 febbraio 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Lo scorso anno Google ha liberato il codice del codec VP8 ed introdotto nel nuovo formato WebM che non è nient’altro che uno stream Matroska. Tutti i principali progetti liberi hanno aggiunto in breve tempo il supporto per WebM e Google lo ha introdotto anche su YouTube.

Ora arriva la notizia che Big G ha intenzione di eliminare il supporto a H.264 dalle future versione di Chrome come codec per HTML5. Il messaggio non è esplicito, ma è ugualmente chiaro, YouTube passerà a WebM e H.264 verrà, in pratica, messo quasi fuori mercato, ma il resto del mondo avrà il tempo di adeguarsi.

Sempre in quest’ottica possiamo leggere gli annunci di un numero sempre crescente di produttori hardware che scelgono di aggiungere il codec WebM all’interno dei loro chip.

La patata bollente arriverà nelle mani di Apple e Microsoft. Se la seconda se la potrà cavare grazie alle future versioni del plugin flash che introdurrà il supporto a WebM la situazione di Apple appare più critica.

Via | OsNews

Google rimuoverà il supporto a H.264 da Chrome é stato pubblicato su ossblog alle 10:00 di mercoledì 12 gennaio 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Nella tarda serata di ieri è stato ufficializzato l’ingresso del supporto sperimentale a WebGL in Google Chrome. WebGL è un’implementazione per il browser di OpenGL ES 2.0 del Khronos Group e permette di visualizzare/interagire con animazioni complesse. Un esempio recente è KataSpace, un mondo virtuale alla SecondLife che è stato realizzato in WebGL ed è accessibile dal browser. Le prospettive che si aprono sono le più disparate.

L’esperimento che sta facendo parlare di sé riguarda la navigazione del corpo umano in 3D: il progetto è stato realizzato al 20% da Google e mostra l’applicazione di WebGL all’apprendimento. Il modello può ruotare e gli organi nascosti o, mostrati sfruttando l’opacità del canale alpha per scoprire ossa, nervi, ecc.; tutto da Chrome e dai browser che supportano WebGL, soprattutto basati sul backend WebKit. Funziona pure su Linux.

È necessario installare la beta di Chrom* per OS X, Windows oppure inclusa tra i pacchetti delle distribuzioni. Non esiste il download diretto per Linux da Google, ma Debian e Ubuntu possono installare Chrome dal repository per APT. Numerosi esempi possono essere visualizzati nella categoria dedicata a WebGL su Chrome Experiments. Un altro passo avanti verso una nuova dimensione del web. Certi progetti sono eccezionali.

Via | Chromium

WebGL è in beta e approda su Google Chrome per Linux, OS X e Windows é stato pubblicato su ossblog alle 11:00 di venerdì 17 dicembre 2010.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Il team di sviluppo dietro a Chrome ha presentato Crankshaft, una nuova infrastruttura di compilazione per V8, il motore javascript del browser made in Google.

Crankshaft riesce a migliorare in maniera sostanziale, come potete veder sopra, le prestazioni delle applicazioni javascript più pesanti grazie ad una attenta analisi del codice in esecuzione ed una ottimizzazione molto spinta delle parti più critiche.

Crankshaft è formato da 4 componenti: un compilatore, un runtime profiler, un ottimizzatore ed un deottimizzatore. Secondo Google il compilatore di base genera codice più veloce e più snello rispetto a quello utilizzato attualmente da V8. Il profiler è in grado di identificare le parti di codice in cui viene spesa la maggior parte del tempo e con queste informazioni l’ottimizzatore lavora sulle parte più critiche per le prestazioni. Il deottimizzatore controlla il codice generato per evitare i piccoli errori di quest’ultimo.

Al momento il codice è disponibile solo per Intel a 32bit, ma si sta già lavorando per le versioni a 64bit ed Arm.

Via | Chromium

Crankshaft per Chrom* é stato pubblicato su ossblog alle 15:00 di giovedì 09 dicembre 2010.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Il plugin Flash continua a dare grattacapi, soprattutto sul versante della sicurezza dove i bug sono sempre troppi.

Google ha annunciato che nella versione di sviluppo di Chrome il plugin verrà fatto girare in una sandbox con privilegi limitati per evitare che alcune falle di sicurezza possano provocare troppi danni all’ignaro utente. Si tratta di una prima versione che migliora notevolmente la situazione attuale, ma che verrà migliorata nel prossimo futuro. La sandbox è attiva in maniera predefinita, ma può essere disabilita lanciando il browser con --disable-flash-sandbox.

Purtroppo questa innovazione è disponibile, per ora, solo per Windows e non è stato specificato quando arriverà anche per gli altri sistemi operativi.

Via | OsNews

Chrom*, flash in gabbia é stato pubblicato su ossblog alle 09:00 di venerdì 03 dicembre 2010.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

A partire dai prossimi mesi i rilasci ufficiali per Chrom* dovrebbero arrivare ogni 6 settimane.

La strategia del “Release Early, Release Often” servirà ad avere una pianificazione delle nuove funzionalità più prevedibile ed eliminare la pressione dei manager sugli ingegneri per “sfornare” una nuova versione.

Una nuova caratteristica non ancora stabile sarà rimandata alla versione successiva. Quindi aspettatevi di vedere le major version in maniera molto rapida.

Via | Chromium

Chrom*: Release Early, Release Often é stato pubblicato su ossblog alle 13:59 di martedì 27 luglio 2010.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.