Archivi categoria: Notizie

Oracle rilascia VirtualBox 5.2.10 e Oracle Linux 7.5

Facebooktwittergoogle_plusredditlinkedin

Settimana di rilasci per Oracle che rende disponibili la versione 5.2.10 di VirtualBox e la versione 7.5 di Oracle Linux.

Per quanto riguarda VirtualBox, questa maintenance version va ad applicare tutte le Critical Patch Updates riguardanti la sicurezza e a risolvere diversi bug:

  • Freeze di KDE Plasma al caricamento, su svariate distribuzioni;
  • Interrupt storm nelle VM FreeBSD con la componente HDA abilitata;
  • Gestione del nameserver 0.0.0.0 come paramento di NAT valido;
  • Possibilità di avere controller NVMe multipli con ICH9 abilitato;
  • Aggiunto controllo su NULL pointer per codice MMIO.

Oracle Linux 7.5 arriva invece subito dopo la release di Red Hat (su cui l’OS di Oracle è basato) ed include:

  • Release 4.1.12-112.16.4 dell’Unbreakable Enterprise Kernel (UEK);
  • Kernel compatibile Red Hat 3.10.0-862;
  • Supporto alle Memory Protection Keys presenti sui recenti processori Intel;
  • Possibilità di sbloccare dispositivi criptati connessi alla rete durante il processo di boot.
  • SSLv3 disabilitato di default in mod_ssl di Apache;
  • KASLR (Kernel address-space layout randomization) abilitato per i guest KVM, feature che rende casuale l’indirizzo delle librerie e delle aree di memoria più importanti al fine di evitare buffer overrun ed exploit.
  • btrfs deprecato nel kernel Red Hat ma completamente supportato da UEK;
  • Supporto (esattamente come in RHEL 7.5) ad OpenSCAP.

Ma c’era davvero bisogno di fare questo Unbreakable Linux?

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😉

Annunciati i nuovi nomi per le future release di Debian

Facebooktwittergoogle_plusredditlinkedin

A partire dal 12 gennaio 2019 il team di Debian inizierà il processo di avvicinamento al rilascio della prossima release, nominata Buster. Quindi nel pieno rispetto della tradizione ecco che anche il cane di Andy, della serie Toy Story, ha la sua release. Al transition freeze di gennaio seguirà il soft freeze il 12 febbraio per arrivare al full freeze il 12 marzo. Quando verrà rilasciata quindi la versione? A conti fatti ed analizzando il corso seguito dalle precedenti release è presumibile che verso la metà del 2019 Buster sarà ufficialmente tra noi.

Ma analizzando la pagina delle release di Debian si possono scoprire altre informazione sui prossimi rilasci previsti dal progetto. Ad esempio già si conosce il nome del successore di Buster, il quale verosimilmente verrà rilasciato nel 2021, che è Bullseye (il cavallo dello sceriffo Woody).

Ma le notizie non finiscono qui, scopriamo infatti da Phoronix che è stato deciso anche il nome della versione 12 che uscirà, sempre calcolando le date con un alto grado di approssimazione, nel 2023: Bookworm (il bruco bibliotecario di Toy Story 3). Curiosa la scelta poiché un software dedicato alla lettura degli ebook si chiama allo stesso modo.

Per l’annuncio ufficiale di tutte queste notizie ecco il link al post della Debian Announce List che riporta le decisioni del release team.

E’ ufficiale: Microsoft ha rilasciato una distribuzione Linux basata su un Kernel personalizzato

Facebooktwittergoogle_plusredditlinkedin

Con il filone “Microsoft ama Linux” ci siamo abituati a vedere comportamenti sempre più controcorrente rispetto alla storia di Microsoft.

Dal rilascio dei propri software in open source, alla collaborazione con Canonical per il rilascio di uno strato Linux in Windows, fino all’inclusione (e promozione) di distribuzioni Linux officiali nello store Azure, pensavamo di aver fatto il callo a questa nuova tendenza.

Ma proprio in un momento di serenità, ecco l’esplosione: Microsoft rilascia una distribuzione Linux.

Si, potete rileggere la frase, c’è proprio scritto quello!

Un paio di giorni fa, infatti, Microsoft ha annunciato una nuova tecnologia chiamata Azure Sphere e pensata per avere un sistema estremamente sicuro per dispositivi IoT, giocattoli connessi ed altri gadget.

E, dovendo fornire un sistema sicuro, da cosa partire? Da Windows? No, molto meglio avvalersi di un kernel Linux (altamente modificabile) e customizzarlo per le loro necessità.

Ed è quello che è stato fatto, scritto nella pietra o, se vogliamo, nel post ufficiale sul blog di Microsoft:

Azure Sphere will bring to these new chips a new customized operating system built for IoT security. This OS incorporates a custom Linux kernel that has been optimized for an IoT environment and reworked with security innovations pioneered in Windows to create a highly secured software environment.

Azure Sphere porterà a questi nuovi chip un nuovo e personalizzato sistema operativo costruito per la sicurezza dell’IoT. Questo OS incorpora un kernel Linux personalizzato che è stato ottimizzato per gli ambienti IoT e rilavorato con innovazioni di sicurezza già utilizzate in Windows per creare un ambiente software altamente sicuro

Quindi si, c’è Linux, ma l’annuncio sembra non dargli troppo credito, sottolineando che hanno dovuto lavorare sul kernel parecchio per renderlo utilizzabile su dispositivi IoT e, soprattutto, “sicuro come Windows” (…).

Il progetto Azure Sphere è molto più ampio, in realtà, e comprende lo sviluppo di chip ad-hoc, l’OS e servizi cloud a compendio di entrambi, ma il fatto che per la parte centrale di tutto (di fatto, è l’OS che fa parlare l’hardware con il cloud) è stato deciso di non usare un sistema Windows -seppur embedded- è sicuramente una svolta sensibile.

Al momento ne nell’articolo di Microsoft, ne nel loro repository GitHub ufficiale è presente il sorgente di questo kernel, stando alla GPLv2 dovranno rilasciarlo per forza… magari stanno aspettando solo la mail di Garrett.

Cosa ne pensate? E’ l’inizio della fine?

Ubuntu 18.04 LTS e Canonical LivePatch: aggiornamenti kernel senza reboot

Facebooktwittergoogle_plusredditlinkedin

Mancano poco meno di due settimane, il 26 aprile, al rilascio di Ubuntu 18.04 LTS (Bionic Beaver) che includerà:

  • Linux Kernel 4.15
  • systemd-resolved sarà il nuovo resolver DNS di default;
  • SSSD aggiornato alla versione 1.16x;
  • X.Org Server come display server di default invece di Wayland;
  • Patch per Meltdown e Spectre;
  • Deprecato Python 2 in favore di Python 3 (versione 3.6).

Una delle novità più interessanti di questa release pero è Canonical LivePatch, un servizio che permette di aggiornare il kernel senza necessità di riavviare il sistema.

In realtà questo servizio era già presente nella scorsa release, la 16.04, ma per questa volta Canonical si è impegnata a rendere questo tool di più facile utilizzo: ora si integra direttamente nella tab Updates, nella sezione dedicata alle impostazioni degli aggiornamenti.

Unici due nei forse:

  • È necessario avere un account Ubuntu SSO;
  • Limitato a 3 sistemi; oltre diventa necessario acquistare una sottoscrizione ad Ubuntu Advantage.

LivePatch è abilitato di default e per ricevere gli aggiornamenti basta semplicemente loggarsi al proprio account. Gli update/patch vengono applicati utilizzando pacchetti Snap.

Che qualcuno poi finisca per usarlo… in produzione?

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.

OpenContainerInitiative: finalmente uno standard per la trasmissione di immagini dei container

Facebooktwittergoogle_plusredditlinkedin

Due anni fa parlavamo della nascita della Open Container Initiative sotto il controllo della Linux Foundation. Con l’esplosione dell’uso dei container, e delle tecnologie in grado di gestirli, definire uno standard ufficiale ed aperto per la creazione, l’esecuzione e la trasmissione delle immagini dei container è diventato fondamentale.

E, finalmente, si inizia ad arrivare a qualcosa di completo: già in passato il formato delle immagini ed i runtime sono stati standardizzati dalla OCI, che l’anno scorso ha raggiunto una maturità con il rilascio della versione 1.0; in questi giorni il lancio del progetto Distribution Specification ha definito lo standard anche per il push e pull delle immagini (le operazioni utilizzate per caricare e scaricare le immagini da un registro), andando così a coprire (quasi) tutto il mondo container: come viene creato, come viene eseguito e come viene trasmesso.

Per questa operazione hanno deciso di basarsi sulla definizione del Docker Registry V2; essendo questo un registry dei più utilizzati al mondo (forse il più utilizzato), è sembrato logico prendere le specifiche di come lavorasse e, sulla base di quelle, costruire uno standard che, tendenzialmente, permetterà l’adozione dalla maggior parte dei sistemi di gestione di container senza grosse modifiche.

Ovviamente Docker non può che essere contenta del fatto che la sua implementazione è diventata lo standard, come affermato da Michael Crosby, ingegnere e maintainer in Docker:

Docker’s contribution of the Docker Registry V2 specification aligns with our history of making key open-source projects available to the community. As with the runtime and image specification, Docker’s registry protocol has become a de facto standard with over 40 billion images pulled using this protocol.

Il contributo di Docker alle specifiche del Docker Registry V2 si allinea con la nostra abitudine storica di rendere i progetti open-source chiave disponibili alla community. Insieme al runtime ed alle specifiche delle immagini, il registry protocol di Docker è diventato lo standard de facto con oltre 40 miliardi di immagini scaricate usando questo protocollo.

La notizia in ogni caso è stata accolta molto positivamente da tutti, sia da Amazon con il suo Amazon Elastic Container Registry (che comunque è compatibile con il Docker Registry V2), sia da Microsoft che eroga l’Azure Container Registry (implementato usando proprio il Docker Registry) che Google, fornitore di Google Cloud (di cui non si sa molto riguardo il funzionamento dei registry forniti).

Tutti contenti dunque, abbiamo uno standard completo!
Ora non resta che aspettare che tutti lo abbraccino.

Cos’hanno in comune BMW, Chevrolet, Honda, Mercedes e Tesla? Sotto il cofano c’è Linux!

Facebooktwittergoogle_plusredditlinkedin

Ebbene sì, il titolo parla da sé: c’è qualcosa che accomuna le case produttrici di automobili BMW, Chevrolet, Honda, Mercedes e Tesla (e non solo), ed è il fatto che tutte appoggino le loro componenti software su Linux.

Attenzione però, il nome di Tesla non confonda, non stiamo parlando (solamente) di macchine a guida autonoma, ma in generale di tutti gli aspetti software delle automobili di ultima generazione.

Come spiega Steven J. Vaughan-Nichols di ZDNet, ormai molte funzionalità delle auto moderne sono gestite non solo elettronicamente, ma informaticamente ed è per questo che l’open-source si presta allo scopo, poiché nella sostanza le case produttrici di automobili stanno diventando vere e proprie Software house.

Pensate che esiste un progetto, sponsorizzato e promosso dalla Linux Foundation, chiamato Automotive Grade Linux che riunisce i produttori di automobili e le aziende che producono accessori e tecnologia per utilizzare una piattaforma comune di sviluppo. Ne avevamo già parlato lo scorso anno per Toyota, e la diffusione di AGL pare inarrestabile.

Ma c’è sempre chi sta un passo avanti agli altri, ed ovviamente stiamo parlando dell’azienda che ha creato la prima macchina spaziale (o che ha lanciato una macchina nello spazio, ad essere precisi, ma non fa molta differenza), Tesla. Partita con Ubuntu alla fine Tesla ha creato il proprio ambiente che evolve ad uno stadio differente rispetto a tutti gli altri, aggiornando componenti (come il kernel, che per tutti era fermo al 2.6.36 e che Tesla ha portato al 4.4.35).

E poteva mancare Google con il suo Linux per automobili? Figurarsi, esiste infatti Android Auto un progetto volto a portare Android sotto il cofano di tutte le auto. Insomma, a dispetto dei discorsi relativi agli utenti desktop Linux che sono sempre pochi il futuro è segnato: magari sul laptop ci sarà Windows, ma mentre digiteremo nella nostra automobile a portarci in giro sarà Linux.

E fermati al benzinaio potremo finalmente chiedere “Mi fa il pieno e mi applica l’ultima patch per Spectre, gentilmente?”