Archivi categoria: Google

Primi effetti su Wine per Oracle vs Google… E se Microsoft dedicesse qualcosa di simile?

Facebooktwittergoogle_plusredditlinkedin

Solo poco tempo fa, nel caso che vede Google contrapposta ad Oracle, abbiamo dato la notizia della decisione della corte di ritenere le API di Java sotto copyright, e il loro uso (con reimplementazione su altri sistemi) da parte di Google illegittimo; ora i primi effetti – la paura – di quella sentenza si cominciano a vedere.

Domenica 1 aprile (Pasqua), nella newsletter di Wine, è comparso un messaggio:

Does anyone know exactly how much this ruling affects Wine? Can we ask the SFC for a legal opinion?

Qualcuno sa esattamente in che misura questa sentenza impatta Wine? Possiamo interpellare l’SFC [Software Freedom Conservancy] per un parere legale?

La preoccupazione nasce dal fatto che Wine rende trasparenti le chiamate alle API per il programma (pensato in origine per funzionare nativamente sotto Windows) e si teme quindi che Microsoft possa intentare una causa simile a quanto fatto da Oracle contro Google. Con un precedente simile la vittoria sarebbe molto probabile.

Come potete ben capire l’analogia è molto forte, tanto che il comitato di gestione di Wine venerdì ha risposto di essere già in contatto con la Software Freedom Conservancy:

The committee has been in contact with Conservancy about this.

Il comitato ha già preso contatto con la Conservancy a questo riguardo.

La Software Freedom Conservancy è un’organizzazione nata nel 2006, che (come la Free Software Foundation) ha l’obbiettivo di promuovere e difendere l’esistenza di software gratuito, libero e open source (FLOSS – Free, Libre, Open Source Software). Conta ormai più di 40 progetti, compresi Git, BusyBox, Boost, Inkscape, QEMU e – appunto – Wine.

Quindi?

As of now, what we’ve learned is that it’s too early to know the effect the decision will have. It’s important to note that the decision isn’t binding on any other courts in the country, and it could be years for the appeals process to complete.

Per ora, quel che sappiamo è che è troppo presto per sapete che effetto avrà la sentenza. È importante notare che la sentenza non lega alcuna altra corte del Paese, e che potrebbero volerci anni per completare il processo di appello.

Insomma, non è ancora stata detta la parola fine. Al meglio, rimandato di qualche anno. Chissà che per allora Microsoft non abbia deciso di regalare le API di Windows alla comunità Linux, di cui ormai fa parte😉

Google e l’OS color Fuchsia

Facebooktwittergoogle_plusredditlinkedin

Che Google abbia sempre qualche cosa in sviluppo, valutazione o sperimentazione è indubbio. Spesso questi progetti sono anche pubblici, ma senza pubblicità che attiri l’attenzione.

Da un paio d’anni ha in sviluppo Fuchsia, un nuovo sistema operativo costruito in casa fin dal kernel, chiamato Zircon. In questi anni ogni tanto è apparso qualche riferimento, ma è rimasto sconosciuto lo scopo, il perché sviluppare un altro sistema operativo. Lo è tutt’ora, ma adesso abbiamo qualche dettaglio su cosa sia Fuchsia, e in cosa si differenzi da quanto già visto.
Google ha infatti pubblicato la documentazione, chiamata The Book.

Fuchsia is not Linux

Fuchsia non è Linux

Le prime parole del documento (nonché il titolo del primo paragafo) servono ad affermare una cosa non ovvia, di questi tempi: il nuovo sistema operativo non è in alcun modo basato su Linux. Fuchsia ha un kernel suo e programmi suoi, tutto fatto in  casa.
Un sistema operativo è formato da almeno due parti: il kernel, che si occupa di gestire l’hardware, ed i programmi base, che danno istruzioni al kernel. Le varie distribuzioni Linux (di cui così spesso parliamo) sono una combinazione del kernel Linux e dei programmi GNU (tanto che sarebbe corretto riferirsi sempre a sistemi GNU/Linux).
Come visto quando abbiamo parlato di Meltdown, lo spazio di memoria assegnato al kernel è separato da quello dei programmi, ed anche quello che può fare il kernel è diverso: dovendo gestire l’hardware, il kernel può mandare dei comandi ai dispositivi, mentre i programmi devono usare il kernel.

Tutto in userland

Leggendo la documentazione salta all’occhio come molte funzioni, che normalmente vediamo parte del kernel (al massimo come modulo da caricare), in Fuchsia siano processi (chiamati servizi) che girano nello spazio utente.
Per esempio, per accedere ad un file normalmente viene chiamato un programma che individua il file in un filesystem (caricato nel kernel), il quale usa un driver (caricato nel kernel) per leggere i dati memorizzati fisicamente sul disco.
In Fuchsia succede una cosa molto simile, ma non identica: un programma chiede il file ad un filesystem (che è un servizio, ovvero un altro programma), il quale chiede informazioni ad un driver (che è un altro servizio) per dare le istruzioni al kernel che legge fisicamente i dati dal disco; la catena di comunicazioni quindi procede a ritroso: il driver comunica il risultato al filesystem che comunica la disponibilità o meno dei dati al programma richiedente.

Scambio messaggi, non dati

Normalmente filesystem e driver devono essere scritti nello stesso linguaggio del kernel, e ne devono condividere le strutture dati visto che usano direttamente quei dati. Questo porta ad uno svantaggio: ad ogni aggiornamento della struttura dati del kernel, il modulo deve essere ricompilato e/o in parte riscritto, per adeguarsi ai cambiamenti.
In Fuchsia i componenti sono programmi a sé stanti che comunicano tra di loro con un protocollo standard: qualunque programma, scritto con qualsiasi linguaggio, sia in grado di comunicare con quel protocollo (chiamato RemoteIO) può svolgere quel compito. Questo vuol dire anche che l’aggiornamento di uno di questi componenti (kernel, filesystem o driver) non implica l’aggiornamento di tutti, e le modifiche di funzionamento o rappresentazione dei dati interno non coinvolge gli altri componenti.

A chi è destinato tutto questo?

Non ci dilungheremo oltre sulle caratteristiche tecniche, che sono peraltro ben approfondibili grazie proprio al Libro di Google. Aggiungiamo solo che l’architettura sembra studiata per avere nativamente certe caratteristiche:

  • un alto livello di sicurezza: ogni processo è indipendente e potrebbe aver accesso solo allo stretto necessario;
  • multipiattaforma: il (micro)kernel e la modularità dei servizi permetterà di avere solo i componenti necessari su hardware embedded, mentre più generale e completo su altri tipi di hardware; inoltre, grazie al sistema a servizi non si è legati ad un linguaggio specifico;
  • facilità di manutenzione: l’aggiunta, l’aggiornamento o la rimozione di un servizio sono istantanei e indipendenti dagli altri.

Queste caratteristiche fanno pensare ad un uso che spazia dai pc ai telefonini, tanto che qualcuno ha già ipotizzato possa essere il futuro sostituto di Android e ChromeOS.
Noi crediamo sia semplicemente un po’ troppo presto per dirlo: il sistema è ad uno stadio di esercizio di stile, non ancora definibile nemmeno come versione Alpha (in cui le funzionalità base sono state implementate), quindi per poter valutare cosa effettivamente sia e dove potrebbe avere senso usare Fuchsia ci vorranno ancora anni.

In compenso, ci fa molto piacere che esista, e che si stia sviluppando tanto velocemente, un’alternativa. Opensource, naturalmente.

Oracle vs Google: la saga per Android continua

Facebooktwittergoogle_plusredditlinkedin

Quasi due anni fa parlavamo di questa stessa vicenda, che ormai si trascina da otto anni. E, incredibilmente, non è ancora finita.

L’oggetto del dibattito è il sistema Android, scritto (in gran parte) in Java, grazie alla sua particolarità di generare del codice eseguibile da una grande varietà di dispositivi tramite un programma, la Java Virtual Machine, specifico per il dispositivo. Le specifiche del linguaggio sono libere, ma le implementazioni sono molte; quella di riferimento è sotto copyright ed era distribuita – gratuitamente – da SUN. Nel 2010 Oracle compra SUN, con la sua implemetentazione, e da allora reclama un risarcimento danni a Google per aver usato Java senza permesso.

Esponiamo l’ultima puntata della saga, ma più sotto trovate un riassunto.

A maggio del 2016 la giuria aveva decretato che quello di Google era a tutti gli effetti un uso equo (fair use), ovvero un uso senza fine di lucro (dato che Android, in sé, è opensource e distribuito gratuitamente). Ma il giudice, pochi giorni fa, ha deciso che questa decisione era tecnicamente sbagliata: il fatto che fosse “poco” codice non implicava fosse “poco importante” (uno dei possibili requisiti per il fair use), e quindi ha ribaltato la sentenza: Google ha torto e deve pagare i danni ad Oracle. Quanto? Altro processo per definirlo, ma Oracle chiede non meno di  8,8 miliardi di dollari: 3 volte il fatturato di RedHat.

Le armi a disposizione di Google per evitare un tale esborso sono molte poche; la più efficacie, il ricorso alla corte suprema della California, potrebbe essere anche la più spuntata: già nel 2014 ha tentato questa strada, e la corte ha semplicemente declinato la richiesta. Forse, questa volta, dovrò davvero pagare.

In realtà il problema non è solo una questione di soldi tra Google e Oracle, ma rappresenta un precedente pericolo per l’opensource in generale, in quanto le API rappresentano il codice “di contatto” tra un programma e l’altro, create proprio con l’intento di essere riusate e distribuite: il precedente per cui sono coperte da copyright e non possono essere nemmeno re-implementate rappresenta un concreto ostacolo al loro riuso, ed al riuso del codice in generale.

La sentenza cerca di limitare l’effetto a questo caso, ma rimane davvero indubbio che uno sviluppatore, prima di usare codice scritto da altri, ci penserà almeno due volte…

Piccolo riassunto

Il contendere è il sistema Android (e nello specifico gli introiti generati da esso), il celeberrimo – e usatissimo – sistema operativo oramai sinonimo di smartphone – almeno come unica alternativa ad Apple ed al suo iOS.
Android è basato su Java, che di per sé è un linguaggio opensource, ovvero le sue specifiche sono di pubblico dominio, ma l’implementazione di quelle specifiche, ovvero il codice che viene effettivamente eseguito da un computer, può essere messa sotto copyright, come qualsiasi altro software. Nello specifico, in questo caso, si parla delle API, ovvero la parte più superficiale dell’implementazione fatta apposta per interagire con altri programmi – o diventarne parte.

Quando Google iniziò lo sviluppo di Android, alcune di queste interfacce non erano disponibili per il Java usato dai telefonini, e pensò di ricreare (copiare, se volete) quelle usate sui PC, prendendo spunto dall’implementazione che era (ed è) quella di riferimento: quella di Sun – nel frattempo comprata da Oracle. Il tutto, però, senza chiedere esplicitamente il permesso.

Appena acquisita Sun, Oracle intenta la (prima) causa, che genera una vera e propria telenovela:

  • 2010 – Oracle dice che sono stati infranti dei brevetti e che le API sono sotto copyright: perde subito sul brevetto. Google sostiene di rientrare nel caso di fair use.
  • 2012 – Oracle perde anche sul copyright: per il giudice le API e il codice sono cose diverse, e le prime non sono coperte; fa ricorso.
  • 2014 – Oracle vince: all’appello si stabilisce che le API sono sotto copyright. Google sostiene che allora rientra in gioco il fair use: la giuria deve esprimersi.
  • 2016 – (puntata scorsa) La giuria stabilisce che Google rientra nella fair use. Ma manca ancora la sentenza…

Ecco come RedHat è riuscita a coinvolgere Google, Facebook e… Microsoft per tutelare al meglio la licenza GPL

Facebooktwittergoogle_plusredditlinkedin

Abbiamo parlato ieri del rinnovato impegno di Microsoft nei confronti delle licenze GPL, ma questo processo da chi è stato avviato e in cosa consiste nel dettaglio?

Si chiama “Common Cure Rights Commitment“(che significa più o meno “Impegno comune per la cura dei diritti”) ed è un progetto avviato da Red Hat lo scorso novembre al fine di consentire di sanare tutti gli errori di conformità e le violazioni in merito alle licenze GPLv2 e LGPLv2.1/v2 a cui ha appunto recentemente aderito anche Microsoft.

Il Progetto viene così descritto:

Before filing or continuing to prosecute any legal proceeding or claim (other than a Defensive Action) arising from termination of a Covered License, [Company] commits to extend to the person or entity (“you”) accused of violating the Covered License the following provisions regarding cure and reinstatement, taken from GPL version 3.

Prima di inoltrare o continuare a perseguire procedimenti legali o reclami (diversi da un’azione difensiva) derivanti dalla cessazione di una licenza coperta, [la Società] si impegna ad estendere alla persona o entità (“tu”) accusata di violare la licenza coperta quanto segue disposizioni in materia di cura e reintegrazione, prese dalla licenza GPL versione 3.

I termini sono piuttosto complicati e “legalesi” (per Covered License o Licenza coperta si intendono le licenze GPLv2, LGPLv2.1 e la GNU Library), ma nella sostanza l’accordo proposto da Red Hat e sottoscritto da grandi compagnie come Facebook, Google, IBM, Cisco e, ebbene sì, anche Microsoft, prevede un periodo di tempo da mettere a disposizione da parte di chi ha violato le licenze per sanare la situazione.

Per essere ancora più chiari: se io Microsoft (!) ho creato del codice rilasciato sotto licenza GPL, prima di intraprendere un’azione legale contro qualcuno che sta usando impropriamente questo codice lascerò un determinato periodo di tempo per fare in modo che la persona (o l’entità) in questione possa sanare la situazione.

A quanti questa cosa può sembrare strana, soprattutto parlando di Microsoft, vale la pena di citare alcuni numeri:

  • Microsoft è un contributor attivo su Github in più di duemila progetti;
  • Il 40% delle macchine virtuali che girano su Azure sono Linux, ed il numero è in costante crescita;
  • Microsoft sta portando le sue principali tecnologie , vedi .NET Core, Visual Studio e via dicendo su Linux ed allo stesso tempo le sta rendendo OpenSource;

Si fa quindi presto a capire come questo accordo tuteli principalmente l’interesse delle compagnie che giustamente vogliono proteggere il proprio know-how ed in generale preservare la tecnologia da usi impropri.

Reptoline, la via di Google per sanare Spectre nei Kernel Linux già disponibile su RedHat

Facebooktwittergoogle_plusredditlinkedin

Le mitigation introdotte dalle varie distribuzioni per risolvere i problemi di sicurezza derivanti dalle falle Spectre e Meltdown non stanno funzionando a dovere. Nessuna novità in questo, ma tra problemi di performance o copertura limitata, ad esempio alcune esclusioni sui processori AMD64, l’impressione è che ci sia ancora molto da lavorare.

Con l’introduzione di Retpolines Google ha cercato di tagliare la testa al toro, facendo in modo che il Kernel abbia il totale controllo sulle esecuzioni speculative (vera causa del disastro) . L’approccio di Google oltre che essere più veloce è anche molto più generico rispetto alle specifiche patch del microcode di Intel, offre quindi una migliore copertura e vien da se che si possa definire una soluzione superiore.

Ebbene, alla luce di tutto questo, Red Hat ha messo a disposizione diverse analisi sulle performance nelle quali viene evidenziata la valenza dell’approccio Reptoline su diversi tipi di carico e ambito di utilizzo. In ogni caso l’approccio retpoline dimezza essenzialmente l’impatto sulle performance.

Come testare tutto questo? Anche in questo caso Red Hat ha reso disponibile una dettagliata pagina di istruzioni che descrive dalla A alla Z cosa è necessario fare, quali CVE sono coinvolti e, addirittura, come automatizzare l’operatività delle patch mediante profili tuned.

Non resta che mettersi al lavoro!

Protezione dei dati nel cloud: la partenership di Acronis con Google Cloud consolida la leadership

Facebooktwittergoogle_plusredditlinkedin

Acronis ha annunciato una nuova partnership strategica con Google Cloud e ha reso noti i piani per potenziare le soluzioni di backup di Acronis tramite l’integrazione con Google Cloud Platform. Il nuovo accordo intende incrementare significativamente il numero di regioni cloud in cui i partner e i clienti Acronis possono archiviare i loro dati. Garantirà […]

Google: Rilasciato Chrome 64

Facebooktwittergoogle_plusredditlinkedin

null

Qualche giorno fa il colosso del web ha rilasciato la versione 64 del noto browser Chrome per Linux, Windows e Mac.
Questa nuova versione del browser Google comprende miglioramenti e novità sia a livello di sicurezza che a livello di nuove features.

Andiamo a vedere brevemente quali sono le principali novità:

  • Rilasciata la fix per le vulnerabilità legate a Meltdown e Spectre
  • Il nuovo Pop-up blocker, ridurrà drasticamente la comparsa di pop-up su alcuni siti
  • I video presenti sulle pagine web in riproduzione automatica saranno disabilitati di default ma abbiamo anche alcune opzioni: questi potranno essere riprodotti automaticamente se già silenziati di default o se l’utente avrà cliccato sulla pagina che sta visualizzando
  • Sistema integrato di protezione contro gli auto-redirect malevoli

Di seguito il link per un approfondimento sulle caratteristiche che abbiamo citato sopra.

Non resta che aggiornare il browser dal sito ufficiale.

Google saluta Ubuntu e da il benvenuto a Debian

Facebooktwittergoogle_plusredditlinkedin

E’ arrivata la conferma ufficiale da parte di Google: per i client presenti nell’azienda, Big G ha deciso di abbandonare Goobuntu, sviluppata internamente e basata sul famoso Ubuntu di Canonical, in favore di gLinux, basa sul ramo testing di Debian.

Anche in questo caso la decisione di Google è stata quella di prendere un prodotto open source, introdurci delle variazioni – ogni pacchetto di Debian Testing viene preso, ricompilato testato e sistemato, introducendo modifiche o patch, prima di aggiungerlo ai repository utilizzati da gLinux – ed utilizzarlo solo internamente, senza rilasciare alcunchè pubblicamente.

Quindi non perdete tempo cercando di scaricare Goobuntu o gLinux, sono di Google e vivranno solo per Google.

La parte interessante è che Google ha rilasciato anche un whitepaper in cui mostra le scelte architetturali per la gestione di un parco client così ampio (stiamo parlando di circa un quarto di milione di macchine): viene utilizzato il sistema Puppet in modalità Masterless!

Sono quindi i client stessi che scaricano da un punto centralizzato le configurazioni puppet e le applicano in locale sulla macchina. Insieme all’uso di PXE e TFTP per l’installazione via rete di queste immagini.

Quindi, grazie a Puppet ed alla combinazione PXE+TFTP, Google è in grado di reinstallare un qualsiasi client all’interno della sua rete in meno di 30 minuti, in maniera autonoma e senza necessità di intervento umano di qualsiasi tipo.

Il tutto per avere un bel desktop con release recenti del software con un’interfaccia grafica GNOME supportata da Wayland.

Non male insomma, anche se a me piacerebbe mettere le mani su uno di questo OS per dare un occhiata sia al lavoro fatto dall’IT di Google, sia a quanta innovazione NON viene riversata nella comunità.

Siete interessati?