Luca Annunziata

Intel non supporta XMir

Canonical dovrà arrangiarsi per i driver compatibili con le GPU di Santa Clara. Il chipmaker non svilupperà per il server grafico in competizione con Wayland per rimpiazzare X11

Roma - Quello di Intel è stata un cambio di idea repentino: pochi giorni dopo aver annunciato il supporto nello sviluppo del kernel Linux al server grafico XMir incluso da Canonical in Ubuntu, Santa Clara ha fatto retromarcia e chiarito che non potrà offrire sostegno al software che concorre con Wayland alla successione dello storico X11. Canonical dovrà arrangiarsi da sola per garantire piena compatibilità della propria distribuzione con le GPU del chipmaker.

"Non approviamo o supportiamo Canonical nel percorso che hanno scelto, e non porteremo avanti lo sviluppo di patch per XMir d'ora in avanti": laconica la dichiarazione di Intel, che entra così nella polemica che ha accompagnato la decisione della casa madre di Ubuntu di staccarsi dall'adozione di Wayland, qualche mese fa ormai, per promuovere il proprio server grafico. Intel da tempo sostiene Wayland e il suo sviluppo, conta nelle proprie file anche il creatore di Wayland Kristian Høgsberg che si occupa pressoché a tempo pieno del progetto software.

A Canonical ora toccherà, come detto, occuparsi da sola del supporto ai chip grafici Intel per mantenere piena compatibilità di Ubuntu con i molti PC e notebook che sfruttano la GPU sempre più spesso integrata direttamente nella CPU. Tutto lo sviluppo dovrà avvenire al di fuori del canale "ufficiale": il tutto mentre, al momento, manca ancora un supporto diretto alle GPU Nvidia e AMD per XMir. (L.A.)
20 Commenti alla Notizia Intel non supporta XMir
Ordina
  • Se perfino una società come intel, una delle più prolifiche nello sviluppo di driver open source, investe in modo limitato, è chiaro che deve distribuire quelle risorse ove ritiene che ci sia maggior ritorno.

    Mir ed Xmir nascono come soluzione unicamente per "U"buntu, al contrario di Wayland e XWayland che sono invece rivolte all'intera comunità...

    -compreso Ubuntu-


    La patch che Chris Wilson ha proposto perchè il suo driver supportasse Xmir sarebbe dovuta essere portata avanti ed adattata di volta in volta alla nuova versione dei driver ed eventuali cambiamenti di Xmir; nonchè mantenuta e corretta da eventuali bug; non è, insomma, la storia di una notte e via, ma un impegno a tempo tuttora indefinito.

    Questo, unito al CLA chiesto da canonical, ossia che qualsiasi contributo sia offerto ai suoi progetti le fornisce automaticamente il diritto di redistribuirlo e modificarlo CON LA LICENZA CHE PIU LE AGGRADA, rende la scelta di Intel di NON supportare Xmir alquanto scontata.

    Resta inteso che Canonical può continuare ad utilizzare la patch, poi ritirata, scritta da C. Wilson, ma, come credo sia giusto, sarà suo onere manutenerla, correggerla ed adattarla nel tempo alle proprie esigenze.

    Ricordo a tutti, inoltre, che ciò di cui si sta parlando è Xmir, non Mir.
    Il problema, insomma, ruota intorno a quello strato che servirà a canonical per effettuare una transizione indolore tra Xorg e Mir.

    Ricordo anche ai meno attenti chem quando Canonical dichiarò la sua intenzione di sviluppare Mir, o meglio, quando disse al mondo "ehi, noi staremmo lavorando a Mir da un pò", Wayland e XWayland erano pubblicamente in sviluppo da anni.
    Ora, posto Xmir è l'equivalente di Xwayland e che mir è l'equivalente di Wayland, è chiaro che Canonical NON ha intenzione di contribuire all'ecosistema GNU/Linux, ma di creare un sottosistema esclusivo per la propria distribuzione.
    Non è escluso ed anzi, è una preoccupazione reale,date anche alcune dichiarazioni rese da Canonical qualche mese fa circa un ipotetico substrato di dipendenze "UbuntuCentriche" che avrebbero reso la vita agli sviluppatori più semplice (non ritrovo il link), che un' applicazione scritta con in mente Ubuntu, potrebbe non essere più portabile su sistemi diversi, alla faccia della libertà.

    Infine chi crede che avere sia Mir che Wayland sia un bene perchè favorisce la concorrenza dovrebbe:
    1 - pensare che parlare di concorrenza in un ecosistema aperto e nel quale non c'è renumerazione o profitto inteso in senso stretto lascia il tempo che ha trovato.
    2 - ripensare per bene a quali siano gli effetti del non unire gli sforzi e a cosa hanno portato nell'ecosistema GNU/Linux.
    non+autenticato
  • anche se bisognerebbe indagare i motivi del cambio di idea... non mi pare tragico... basta e avanza Wayland (visto poi che X11 e' ancora vivo e vegeto)
    non+autenticato
  • I motivi sono esclusivamente "politici": mettono i bastoni tra le ruote a un prodotto rivale nella speranza di limitarne la diffusione. Pensa come sarebbe il kernel linux se Torvalds ai tempi si fosse comportato così!

    La cosa dal punto di vista di Canonical non complica più di tanto le cose: la patch l'hanno sviluppata loro e l'avrebbero anche mantenuta, Launchpad è in grado di pescare ogni commit upstream e riapplicarlo al branch che si userà su Ubuntu.

    Di contro chi ci rimette è la comunità che ha meno libertà. In particolare per le non derivate Ubuntu diminuiscono le possibilità di avere il futuro Unity8 (con tutto quello che ne sarebbe seguito: convergenza con tablet e mobile, nuovi applicativi con interfacce responsive e così via).

    Infine questo chiude definitivamente il discorso sul perchè anche oggi Unity non è altrove: upstream alcune aziende bloccano PER I LORO INTERESSI il lavoro dei rivali (vedi le patch rifiutate su gnome libs e GTK).
  • 1)l'ostracismo nel mondo FOSS è all'ordine del giorno, basti guardare cosa è successo al BFS di Kolivas, che non andava giù al dev di CFS
    2)Nessuna distro, derivata o meno di Ubuntu, usa Unity di default, unity è stato pensato e programmato esclusivamente per ubuntu.. non è che tutti odiano canonical, è che non fa ilo minimo sforzo per aiutare la community
    3)ancora no, la lite è avvenuta quando volevano far supportare upstream le loro patch, peccato che loro non contribuiscono minimamente a GTK o Gnome, che è praticamente mantenuto in piedi da Red Hat.
    non+autenticato
  • 1- il fatto che sia all'ordine del giorno non significa che debba piacermi. E' una stronzata a prescindere da chi la applica perchè chi ci rimette è l'utente finale.

    2e3- Vatti a rileggere in ML i rifiuti alla patch di Canonical. Se sono rifiutate su GTK le patch necessarie per unity non diamo a Canonical le colpe. X Unity8 Jono Bacon e Michael Hall hanno sempre detto che Canonical è a disposizione di CHIUNQUE voglia portare Unity8 altrove!

    Il fatto è che IMHO alcune aziende oggi controllano e plagiano il pensiero della comunuità. Un esempio è la balla creata intorno ai server grafici.
    In linux TUTTO è disponibile in almeno 3 versioni. Pensa a quanti FS ci sono nel kernel, addirittura esistono TRE alternative per i driver grafici ATI/AMD. Ma Canonical che crea un suo server grafico si racconta che danneggia la comunità quando in realtà è da sempre il contrario. Apache era un progetto lento e poco dinamico, l'arrivo di nuovi competitor dato nuova linfa all'intero settore.
    -----------------------------------------------------------
    Modificato dall' autore il 10 settembre 2013 20.37
    -----------------------------------------------------------
  • Ma quali sono i vantaggi di XMir su Wayland da essere necessaria questa duplicazione su un componente così importante?
    iRoby
    6911
  • 1- Concorrenza. Avere un "avversario" porta maggiore attenzione e risorse.
    2- E' MIR, non X-mir. Xmir, al pari di xwayland è un livello intermedio di compatibilità tra X e i nuovi server grafici (più in dettaglio è un driver del server grafico).
    3- Prendi con le pinze queste mie dichiarazioni perchè ho letto tanto in giro ma spesso info incomplete e frammentarie. CMQ: Wayland è arrivato ad essere oggi un "clone moderno" di X, replicandone l'architettura client server. MIR punta ad essere più snello e "verticale". Niente supporto per server remoti e un'architettura basata su API. Inoltre mentre Mir è nato per funzionare in ambito mobile per poi supportare il desktop Wayland è nato per fare tutto.
    In teoria MIR dovrebbe essere più snello, Wayland più completo.

    Perchè non dovrebbe valer la pena vederli entrambi?

    P.s. KDE, Gnome, XCFE. Nautilus, Nemo, Marlin. Gstreamer, Xine, FFmpeg. In praticamente ogni campo del free software troviamo un buon numero di alternative. Perchè negarcene in ambito server grafici?
  • Più che altro perché è un componente importante che potrebbe portare numerose incompatibilità.

    Ci abbiamo messo tanto per avere con X.org un supporto per un così vasto numero di chip e schede grafiche che ora con i nuovi server ci troveremo le aziende che non supporta uno o l'altro progetto.

    Ed il software avrà problemi con uno o l'altro server.

    Molti componenti di Linux sono ad una maturità eccellente. Il dover rifare tutta la trafila dei malfunzionamenti, il mancato supporto ecc. Ad un componente così importante mi fa venire il panico.
    iRoby
    6911
  • - Scritto da: barra78
    > 1- Concorrenza. Avere un "avversario" porta
    > maggiore attenzione e
    > risorse.

    Il problema quando si ha una duplicazione a questo livello è che si creano delle incompatibilità fra i programmi. Se ci sono 10 driver o 10 DE chissenefrega, io uso quello che mi va e non creano nessun problema, posso usare kate su gnome e con ati o nvidia, ma due display server rischiano di portare al punto in cui non potrò far girare $app perchè non è compatibile con wayland. Guarda xmir e xwayland, servono perchè x è incompatibile con mir/wayland. ci sarà anche bisogno di mirwayland e waylandmir?

    > 2- E' MIR, non X-mir. Xmir, al pari di xwayland è
    > un livello intermedio di compatibilità tra X e i
    > nuovi server grafici (più in dettaglio è un
    > driver del server grafico).
    >
    > 3- Prendi con le pinze queste mie dichiarazioni
    > perchè ho letto tanto in giro ma spesso info
    > incomplete e frammentarie. CMQ: Wayland è
    > arrivato ad essere oggi un "clone moderno" di X,

    chiamare wayland un clone di X è un'assurdità, è tutta un'altra cosa. sarebbe come dire che un elicottero è un clone di un aereo perché volano entrambi.

    > replicandone l'architettura client server. MIR

    questo è ovvio. c'è il server (il compositor nel caso di wayland, x nel caso di x11 e unity (credo) nel caso di mir) e ci sono i client (le applicazioni). mica puoi fare un unico processo.

    > punta ad essere più snello e "verticale". Niente
    > supporto per server remoti e un'architettura

    wayland non ha alcun supporto per server remoti.

    > basata su API. Inoltre mentre Mir è nato per

    che vuol dire basata su API? se non hai un'API come fai realisticamente a programmare per qualsiasi display server? ovvio che wayland come x e come mir ha un api. anzi due, una lato client e una lato server.

    > funzionare in ambito mobile per poi supportare il
    > desktop Wayland è nato per fare tutto.
    >
    > In teoria MIR dovrebbe essere più snello, Wayland
    > più completo.
    >
    >
    > Perchè non dovrebbe valer la pena vederli
    > entrambi?
    >
    > P.s. KDE, Gnome, XCFE. Nautilus, Nemo, Marlin.
    > Gstreamer, Xine, FFmpeg. In praticamente ogni
    > campo del free software troviamo un buon numero
    > di alternative. Perchè negarcene in ambito server
    > grafici?
    non+autenticato
  • - Scritto da: giucam
    > chiamare wayland un clone di X è un'assurdità, è
    > tutta un'altra cosa. sarebbe come dire che un
    > elicottero è un clone di un aereo perché volano
    > entrambi.


    Se rileghi sopra parlo di caratteristiche e funzionalità. replicherà in pratica tutto quanto presente in X (comprese le funzionalità di neetworking. Sarà un progetto molto migliore, più stabile, semplice da mantenere e certamente performante.

    > questo è ovvio. c'è il server (il compositor nel
    > caso di wayland, x nel caso di x11 e unity
    > (credo) nel caso di mir) e ci sono i client (le
    > applicazioni). mica puoi fare un unico
    > processo.

    I componenti base di wayland sono libwayland-server, libwayland-client, libwayland-EGL, senza entrare troppo nel dettaglio il client non esiste in MIR.


    > wayland non ha alcun supporto per server remoti.

    Leggevo che è stato introdotto recentemente....

    > che vuol dire basata su API? se non hai un'API
    > come fai realisticamente a programmare per
    > qualsiasi display server? ovvio che wayland come
    > x e come mir ha un api. anzi due, una lato client
    > e una lato
    > server.

    Tecnicamente le cose sono molto diverse, qui viene spiegato qualcosa (questi dati sono quelli corretti, non le baggianate uscite il giorno dell'annuncio di MIR): https://wiki.ubuntu.com/Mir/Spec?action=show&redir...
  • - Scritto da: barra78
    > - Scritto da: giucam
    > > chiamare wayland un clone di X è
    > un'assurdità,
    > è
    > > tutta un'altra cosa. sarebbe come dire che un
    > > elicottero è un clone di un aereo perché
    > volano
    > > entrambi.
    >
    >
    > Se rileghi sopra parlo di caratteristiche e
    > funzionalità. replicherà in pratica tutto quanto
    > presente in X (comprese le funzionalità di
    > neetworking. Sarà un progetto molto migliore, più
    > stabile, semplice da mantenere e certamente
    > performante.

    D'accordo, ma ciò non toglie che Wayland non è né sarà mai un clone di X.

    >
    >
    > > questo è ovvio. c'è il server (il compositor
    > nel
    > > caso di wayland, x nel caso di x11 e unity
    > > (credo) nel caso di mir) e ci sono i client
    > (le
    > > applicazioni). mica puoi fare un unico
    > > processo.
    >
    > I componenti base di wayland sono
    > libwayland-server, libwayland-client,
    > libwayland-EGL, senza entrare troppo nel
    > dettaglio il client non esiste in
    > MIR.

    No, non può non esistere. Tu scrivi un'applicazione grafica, questa si connette tramite qualsiasi sistema con un'altra applicazione che si preoccupa di mostrare a schermo quello che l'applicazione disegna e le manda eventi di input. La tua applicazione è il client e quella che gestisce lo schermo è il server. Il client si connette con il server. client/server non significa connessioni remote.
    Non avere client vuol dire non avere applicazioni.

    >
    >
    > > wayland non ha alcun supporto per server
    > remoti.
    >
    > Leggevo che è stato introdotto recentemente....

    Weston, non Wayland, ha un backend RDP, ma non ha nulla a che fare con il networking di X.

    >
    > > che vuol dire basata su API? se non hai
    > un'API
    > > come fai realisticamente a programmare per
    > > qualsiasi display server? ovvio che wayland
    > come
    > > x e come mir ha un api. anzi due, una lato
    > client
    > > e una lato
    > > server.
    >
    > Tecnicamente le cose sono molto diverse, qui
    > viene spiegato qualcosa (questi dati sono quelli
    > corretti, non le baggianate uscite il giorno
    > dell'annuncio di MIR):
    > https://wiki.ubuntu.com/Mir/Spec?action=show&redir

    Non vedo accenni all'api in quella pagina. Chiaro che ci saranno differenze, ma dire che mir è diverso da wayland perché ha "un'architettura basata su API" è come dire che biancaneve è diverso dal re leone perchè è un cartone animato.
    non+autenticato
  • - Scritto da: giucam
    > wayland non ha alcun supporto per server remoti.
    Ha RDP integrato.
    non+autenticato