Secondo quanto pubblicato recentemente sembra che Google stia cercando di far pesare molto di più il suo controllo sulla piattaforma Android nei confronti degli produttori di device.

Sembra che BigG abbia contattato tutti i maggiori produttori per informarli che per rimanere aggiornati sulle ultime versioni del sistema operativo, prima che vengano distribuite pubblicamente, dovranno ottenere l’approvazione di Andy Rubin, capo del gruppo Google che sviluppa Android sia per quanto riguarda le modifiche che vengono apportate al codice sia per quanto riguarda le partnership stipulate con altre aziende.

Quando, nel 2008, Android divenne notizia pubblica furono in molti ad essere entusiasti dell’idea proposta. I produttori potevano sfruttare una piattaforma valida e condivisa senza dover spendere milioni nelsuo sviluppo, gli utenti avrebbero potuto godere dei vantaggi di un sistema più libero rispetto alla concorrenza e Google avrebbe avuto accesso al ricchissimo mercato della pubblicità e ricerca mobile.

Siamo nel 2011 e sembra che negli ultimi mesi BigG abbia aggiunto alcune clausole di non frammentazione che danno all’azienda la possibilità di veto su ogni tipo di modifica effettuata ad Android. Lo scopo dovrebbe essere quello di fornire un comune denominatore alla user exprience. Tutti i modelli di tablet con Android 3.0 sembrano infatti molto simili, ma una volta che i sorgenti diventano pubblici tutti i produttori, grandi o piccoli, potranno modificarli come preferiscono facendo arrivare una seconda ondata di device.

Contemporaneamente questo atteggiamento mette in grande svantaggio tutte quelle compagnie più piccole che possono iniziare a lavorare solo dopo e non riescono a tenere il passo dei produttori più importanti per le minori risorse a disposizione. In un ambiente rapido come IT questo equivale quasi ad una condanna a morte. Come esempio si può citare il caso di un nuovo device presentato nel corso di questo mese ed equipaggiato ancora con Android 2.1.

Arrivati a questo punto non resta che chiedere a voi cosa fareste. Preferite politiche più stringenti, ma con meno frammentazione ed innovazione o politiche più liberali con sicuramente più frammentazione e, potenzialmente, più innovazione?

Via | BusinessWeek

Google, più controllo su Android é stato pubblicato su ossblog alle 14:30 di giovedì 31 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Mozilla ha ufficialmente comunicato che ha intenzione di non supportare più l’embedding del suo motore di rendering HTML Gecko. Questo passo avrà delle grosse ripercussioni su tutti i progetti che usavano questo motore al loro interno per la visualizzazione di pagine HTML. Dovranno, quindi, scegliere se mantenere la funzionalità da soli o passare a qualche altro concorrente, come WebKit.

La motivazione dietro a questa scelta va ricercata nella difficoltà di gestire l’embedding ora che si sta migrando verso il modello di rendering con più processi e con la volontà di dare più priorità a Firefox come prodotto completo. Questo significa che, in futuro, se ci saranno sia la volontà sia le risorse umane il supporto per l’embedding di Gecko potrebbe tornare, ma per ora verrà rimosso il codice per Gtkmozembed, Javaxpcom e per i controlli ActiveX che sono ora all’interno del codebase. Qualcuno si è mostrato interessato a portare avanti il supporto, ma vedremo in futuro se la cosa si sarà concretizzata.

Sicuramente dopo aver rimosso il supporto un successivo reintegro risulterebbe poco interessante. Quanti progetti potrebbero basarsi su un motore che potrebbe di nuovo non essere disponibile in un futuro?

Foto | barron
Via | HOnline

Mozilla elimina il supporto per l embedding di Gecko é stato pubblicato su ossblog alle 15:00 di giovedì 31 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Lennart Poettering di Red Hat ha recentemente caricato una nuova versione di systemd in Fedora 15 che a sua volta porta alla creazione della nuova directory /run nella root. Poiché è un argomento che interessa anche gli utenti di altre distribuzioni vogliamo spiegarvi cos’è e quali sono le motivazioni dietro alla sua creazione.

Anche se da un punto di vista tecnico si tratta di una modifica minimale ha implicazioni più profonde sulla “pulizia” dei futuri sistemi GNU/Linux.

Da svariato tempo ormai ci sono alcuni programmi che hanno la necessità di immagazzinare alcune informazioni su file già durante le primissime fasi del boot. Il primo di questa lista è udev che salva i suoi dati in /dev/.udev come potete controllare sul vostro computer, ma ci sono tanti altri esempi simili che creano file in directory nascoste all’interno di /dev come mdadm, systemd e tanti altri. Se qualcuno sta pensando di suggerire l’utilizzo di /var/run va fatto ricordare che /var, o anche solo /var/run, potrebbero essere su un filesystem differente e quindi disponibile solo nelle ultime fasi del boot.

Questo ha portato gli sviluppatori a cercare una directory in cui immagazzinare i dati, ma l’unica utilizzabile, /dev, è sempre stata poco appropriata. Alcune distribuzioni hanno provato nel corso del tempo a migliorare la situazione, ma con soluzioni che erano specifiche e non condivise con le altri distro.

Da tempo era necessario trovare un punto d’incontro per sistemare questo problema e nei giorni scorsi i rappresentanti delle maggiori distribuzioni si sono accordati per la creazione di /run in cui verranno salvati tutti questi file chiudendo, finalmente, l’epoca delle directory nascoste sotto /dev. Per arrivare a questa decisione abbiamo dovuto aspettare molto tempo perché in molti temevano l’ondata di flame che sarebbero scaturiti in molte mailing list, ma con questo approccio condiviso ed una spiegazione chiara sulle motivazione alla base di questo cambiamento si spera che la modifica venga ben accolta da tutti gli utenti.

Fedora e Suse hanno già adottato /run. Debian lo proporrà per la prossima versione e Ubuntu ha già deciso di introdurre /run. Dracut, udev, systemd sono già stati aggiornati dagli sviluppatori upstream per utilizzare la nuova dir /run, mentre altri strumenti come mdadm e mount verranno modificati molto presto.

Ora arriviamo ai dettagli implementativi per Fedora:

• /run sarà un tmpfs
• /var/run sarà /run rimontato con l’opzione “bind”
• /var/lock sarà /run/lock rimontato con l’opzione “bind”
• le normali applicazioni continueranno ad utilizzare /var/run
• i programmi che hanno bisogno di spazio dove scrivere nelle prime fasi di boot potranno usare /run
• in futuro i bind mount saranno rimpiazzati da symlink

Grazie a questo approccio ci sarà un solo tmpfs che conterrà /run, /var/lock e /var/run semplificando quindi la gestione dei file relativi. Non ci saranno più file nascosti e tutte le distribuzioni saranno standardizzate sul medesimo layout.

Via | GMane

Cos è /run e da dove salta fuori? é stato pubblicato su ossblog alle 12:30 di giovedì 31 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Martedì, AMD ha rilasciato gli ultimi driver proprietari per Linux: i Catalyst 11.3 non aggiungono granché rispetto al passato, perciò non ne abbiamo parlato subito. Poche ore fa, però, AMD ha aggiornato il backport dei prossimi Catalyst 11.4 per Ubuntu/Natty inserendo due funzionalità di sicuro interesse per tutti gli utenti Linux.

Se per il supporto a X.Org Server 1.10 si dovrà comunque attendere il mese di maggio (coi Catalyst 11.5), i driver forniti con Natty Narwhal prevedono il supporto al kernel 2.6.38: Alberto Milone, il packager di Canonical, smentisce l’annuncio di Phoronix circa il supporto preliminare ad AMD PowerXpress… previsto anche per Linux.

Riassumendo, i Catalyst presenti nei repository di Ubuntu 11.04 sono pronti per l’installazione manuale: il comando aticonfig --initial per generare il file xorg.conf non è più necessario, perché i moduli sono caricati automaticamente all’avvio di X. AMD PowerXpress per lo switching delle GPU, al contrario, non è ancora supportato.

Via | Phoronix

Canonical ha avuto il backport dei Catalyst di AMD per Natty Narwhal é stato pubblicato su ossblog alle 09:00 di giovedì 31 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Finalmente, dopo tantissimi anni di lavoro, il linguaggio C++ sta per essere aggiornato dato che l’ISO steering committee per il linguaggio ha approvato l’ultima proposta per il nuovo standard.

L’ISO/IEC Information Technology Task Force (ITTF) avrà valutato il lavoro presentato, se non ci saranno complicazioni tali da sollevare un’obiezione, il nuovo C++ sarà standard entro l’anno e sarà chiamato C++ 2011. Questo segna un passo molto importante per la crescita del linguaggio che oggi si trova al terzo posto nella classifica dei più utilizzati subito dopo Java e C.

Le migliorie e le nuove funzionalità sono molte tali da poter quasi definire il C++ 2011 un nuovo linguaggio anche se mantiene le sue radici storiche. È già possibile provare alcune delle nuove caratteristiche grazie alle estensioni che alcuni compilatori già includono, come il GCC, o attraverso librerie esterne come Boost.

Tra le caratteristiche più importanti si potrebbero citare:

• deduction of a type from an initializer
• copying and rethrowing exceptions
• Delegating constructors
• In-class member initializers
• Lambdas
• Inherited constructors
• Range for statement
• Suffix return type syntax

Via | Cio

Il C++ sta per avere un nuovo standard é stato pubblicato su ossblog alle 16:59 di mercoledì 30 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Cree.py è un nuovo software scritto in Python e rilasciato sotto licenza GPLv3 che è in grado di sfruttare i metadati di geoposizionamento che possono essere recuperati dalle reti sociali e dalle immagini caricate online per ricostruire i movimenti di una persone e tracciarne gli spostamenti.

Yiannis Kakavas, l’autore, pensa che questo strumento possa diventare utile per fare in modo che la gente capisce il grosso problema di pubblicare informazioni così personali e sensibili online. Quindi non si tratta di un tool per stalker, ma per far maturare una corretta sensibilità al problema nell’opinione pubblica in modo che possa scegliere consapevolmente se rendere pubblici o meno questo tipo di dati.

Al momento Cree.py è in grado di recupare geotag da Twitter, Foursquare, metadati Exif nelle foto presenti su Flickr, Twitpic, Yfrog, Img.ly, Plixi, Twitrpix, Foleext, Shozu, Pickhut, Moby.tu, Twitsnaps e Twitgoo. I dati sono visualizzati all’interno di un programma che sfrutta le GTK+ e che mostra la posizione sulla mappa utilizzando i servizi di Google, Virtual Maps o Open StreetMap.

Via | Cree.py

Cree.py é stato pubblicato su ossblog alle 16:00 di mercoledì 30 marzo 2011.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.