di  -  martedì 2 novembre 2010

Wayland è un protocollo di comunicazione nato dalla volontà di fornire un sistema grafico moderno costruito sopra alle nuove tecnologie del kernel linux (Kernel Mode Setting e Direct Rendering Manager). Lo scopo prefissato dal suo ideatore Kristian Høgsberg è quello di creare un nuovo display server che implementasse soltanto la piccola parte delle tantissime feature del protocollo X11 che vengono realmente utilizzate nei moderni gestori di finestre che utilizzano un qualche sistema di compositing.

Il protocollo attualmente utilizzato da tutte le distribuzioni GNU/Linux è il vecchio X. La prima apparizione dell’ultima revisione del protocollo (X11) risale addirittura al 1987. Ovviamente negli anni il protocollo è stato aggiornato e modificato aggiungendo man mano nuove caratteristiche e migliorandone l’implementazione di riferimento. Se da una parte questo dimostra come le scelte di design iniziali siano state abbastanza lungimiranti da far sopravvivere il progetto così a lungo (in questo momento sto digitando in una finestra disegnata grazie al server X) dall’altra è innegabile che tutti gli anni che sono passati si facciano sentire.

Per capire le differenze tra i due protocolli e i motivi dello sviluppo di Wayland in questa serie di articoli mi occuperò di tradurre e dove possibile integrare l’esempio del sito ufficiale del progetto in cui si analizza il flusso di interazioni tra le varie componenti dall’occorrenza di un evento di un dispositivo di input (il classico click del mouse) a quando i cambiamenti che questo evento porta vengono rappresentati su schermo (per esempio il ridimensionamento di una finestra).
Nel nostro primo appuntamento vedremo cosa avviene attualmente nello scenario in cui si stia utilizzando X server ed un composite manager.

  1. Il kernel riceve un evento da un dispositivo di input e lo spedisce ad X attraverso il driver evdev. Il kernel compie tutto il lavoro necessario per gestire la periferica e tradurre la comunicazione specifica del dispositivo in nello standard per gli eventi evdev.
  2. Il server X determina quale finestra è interessata all’evento e spedisce l’evento ai client selezionati per lo specifico evento su quella determinata finestra. Il server X in realtà non sa come farlo in maniera corretta poiché la posizione della finestra sullo schermo è controllata dal compositor e potrebbe essere trasformata in un modo che il server non ha modo di conoscere (pensate alle finestre tremolanti di e ad i vari effetti grafici di compiz o kwin).
  3. Il client analizza l’evento e decide cosa fare. Spesso l’interfaccia utente deve riflettere dei cambiamenti in risposta ad un evento, di conseguenza il client manderà indietro una richiesta di rendering al server X.
  4. Quando il server riceve la richiesta, la spedisce al driver che si occupa di programmare l’hardware per il rendering. Il server calcola anche i confini della regione interessata dal rendering e la invia al compositor sotto forma di “damage event”
  5. Il “damage event” dice al compositor che qualcosa è cambiato nella finestra e quindi deve ricomporre la parte di schermo dove la finestra è visibile. Il compositor è il responsabile per il rendering dell’intero contenuto dello schermo in base al proprio scenegraph e al contenuto delle finestre. Ancora una volta bisogna ripassare attraverso l’X server per renderizzare la scena.
  6. Il server X riceve la richiesta di rendering dal compositor . A questo punto o copia il back buffer del compositor sul front buffer o fa un pageflip. Nel caso generale, il server X deve fare questo passaggio per poter considerare le finestre sovrapposte che potrebbero necessitare il clipping e determinare se può o non può fare il pageflip. Per un compositor che funziona a tutto schermo questo passaggio è non necessario.

Un approccio di questo tipo porta con se diversi problemi. Il server X non ha le informazioni per decidere quale finestra deve ricevere l’evento, e non può trasformare le coordinate dello schermo in coordinate locali della finestra. Inoltre, nonostante X abbia delegato la responsabilità di disegnare lo schermo al compositing manager, ancora controlla il frontbuffer e il mode setting.

La maggior parte della complessità che veniva in passato gestita dal server X è attualmente gestita all’interno del kernel o in altre librerie. Nella pratica, il server X è ormai un entità che non fa altro che inserire uno strato non necessario tra l’applicazione ed il compositor e tra il compositor e l’hardware.

La prossima settimana vedremo le scelte fatte nella progettazione di Wayland.

39 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    TheKaneB
     scrive: 

    al rogo X :D

  • # 2
    Giulio85
     scrive: 

    Era ora.

    In termini di reattività, ogni volta che vado su una qualsiasi distro Linux (tipo quella da cui sto scrivendo, Arch) è una pena.

    Come pure secondo me non viene gestito bene lo switching delle varie frequenze della GPU (nel mio caso nVidia M 8400GS), e questo porta ad avere spesso rallentamenti, del tipo che con Chromium lo scrolling delle pagine è lento.

  • # 3
    j
     scrive: 

    “protocollo” è la parola giusta :)

    anche se wayland è un progetto che ho visto nascere e svilupparsi pezzo per pezzo di codice a partire da un semplice redraw loop, (quindi senza BDUF), quindi in un modo che farebbe pensare che l’ importante sia il server grafico in sè – ma in effetti l’ aspetto fondamentale è il riprogettare meccanismi di base (ad esempio per il drag and drop) allontandosi da x11 e dalla selva di specifiche e API accessorie orbitanti intorno ad esso…
    il problema insito in ciò è che applicazioni e toolkit necessitano di essere adeguati

    ora, gli sviluppatori di queste nel tempo hanno sostanzialmente cercato di mascherare il più possibile le ineleganze (eufemismo), le idiosincrasie e la complessità di interfacciarsi con X incapsulandole il più possibile e coprendole il più possibile con strati di astrazione, per sporcarsi le mani con esse il meno possibile in seguito
    ma se già l’ adozione di un’ altra libreria di interfacciamento col protocollo X (XCB, più “streamlined” di Xlib) ha incontrato resistenza e difficoltà, non posso fare a meno di pensare che passare a nuovi protocolli e nuove API e ABI, ne possa solo incontrare di maggiori …

    Se da una parte questo dimostra come le scelte di design iniziali siano state abbastanza lungimiranti da far sopravvivere il progetto così a lungo

    non sottovalutare il fattore inerziale… ;)
    nello stesso periodo in cui usciva X11 esistevano altri window system più moderni e innovativi (vedi il NewS di Sun) – ma a quel punto esisteva già parecchio codice scritto per X10 legato a che quindi sarebbe stato più facilmente portato – a maggior ragione per uno standard accademico, piuttosto che per un sistema legato un singolo vendor
    poi nel tempo la massa di codice è andata aumentando perchè … non c’ era altro (non nell’ ambiente unix), e questo ha reso sepre più difficile affrancarsi da X come sistema e protocollo grafico – questo nonostante non pochi ne fossero insoddisfatti, (magari per specifici aspetti come le latenze di input -> redraw)
    ma altrettanti lo ritenevano adeguato o superiore per altre, come la network transparency, quindi affrancarsene avrebbe scontentato questi ultimi…

  • # 4
    Cesare Di Mauro
     scrive: 

    @j: concordo. Quando ho letto la parola “protocollo” m’è venuta fuori la stessa frase di TheKaneB. :D

  • # 5
    shodanshok
     scrive: 

    Mha, sono un po’ scettico…
    Fermo restando che X è effettivamente vecchio e lento (soprattuto, le libX standard hanno l’handicap di essere sincrone, mentre le XCB per lo meno sono asincrone), personalmente penso che la maggior parte dei lag visibili siano attribuibili alla corrente implementazione dello stack GTK + Cairo + Pango.

    Questi componenti fanno un pesante uso dell’FPU legacy (X87) e solo marginalmente usano le istruzioni vettoriali SSE/2/3 (molto utili in ambito grafico). Anni fa ricordo che provando delle applicazioni QT 3.x su un vecchio P3 avevo prestazioni di redraw molto migliori rispetto a simili applicazioni GTK 2.x. Addirittura, su un Celeron 1 GHz, Firefox era quasi inutilizzabile fino a che non veniva disabilitato Pango e, in ogni caso, Opera rimaneva molto più veloce (parlo di scrolling della pagina, _non_ del rendering della stessa).

    Un paio di mesi fa ho profilato il redraw di un elemento GtkTree e ho visto un uso di CPU spaventoso per quello che l’elemento fa.

    Non voglio dire che un sistema come quello qui descritto (con le applicazioni che fanno direct rendering) non avrebbe vantaggi, anzi. Il punto è che è più urgente “correggere” il toolkit grafico più diffuso (GTK) e le altre librerie che ci girano intorno. Leggevo che le GTK 3.0 dovrebbero fare dei passi concreti passi avanti proprio in questo senso…

    Ciao.

  • # 6
    homero
     scrive: 

    il fatto di mettere al rogo X11 è una vecchia battaglia combattuta da molti me compreso.

    in questo l’apple ha fatto scuola basandosi sul vecchio motif ed evolvendolo facendo gestire al driver che pilota l’hardware video tutto quello che era possibile senza avere un duplicato o un triplicato del buffer in ram

    questa strada è quella che debba essere intrapresa sopratutto alla luce dei nuovi processori con GPU integrata, che sempre più spesso popoleranno i nostri sistemi.

    pertanto prima di definire un sistema di gestione delle finestre bisognerebbe definire su quale harware lo vogliamo strutturare

    se si vuole fare un windows manager generalizzato ed \astratto\ allora meglio tenersi X11….

    la chiave di tutto è proprio nell’hardware…
    ricordo che un windows manager deve basarsi essenzialmente su due elementi:

    il primo è l’interfaccia con l’utilizzatore

    il secondo è l’output a video

    benchè i puristi tendono da decenni a rendere astratti questi due elementi prescindere dall’hardware significa essenzialmente commettere lo stesso errore che si è commesso con X11…

    premetto che questa idea fu già alla base di alcuni sistemi SGI basati su irix e opengl utilizzati negli anni novanta per alcuni similatori utilizzati in ambito scientifico e non solo….ovviamente non ebbe alcun seguito commerciale se non la diffusione delle famose librerie….

  • # 7
    j
     scrive: 

    in questo l’apple ha fatto scuola basandosi sul vecchio motif

    MacOS aveva API proprie, e quelle presenti in OSX costituiscono sostanzialmente un’ evoluzione di OpenStep, a sua volta framework a oggetti proprio del NextStep (l’ OS sviluppato dall’ “altra” società di steve jobs e poi preso come base per il futuro Mac OS X) – Motif quando sarebbe stato alla base di una sistema Apple?

    ed evolvendolo facendo gestire al driver che pilota l’hardware video tutto quello che era possibile senza avere un duplicato o un triplicato del buffer in ram

    diciamo che su OSX è stato fatto all’ inizio del nuovo millennio quello che con linux si sta facendo solo ultimamente – accelerare il desktop tramite la gpu e al tempo stesso ridurre X a un modulo di compatibilità ad uso delle applicazioni non native OSX…

    se si vuole fare un windows manager generalizzato ed \astratto\ allora meglio tenersi X11….

    X come protocollo e architettura alla base di GUI, è subottimo di suo – leggendo http://www.std.org/~msm/common/protocol.pdf, il capitolo 7 di http://simson.net/ref/ugh.pdf o http://xorg.freedesktop.org/wiki/Development/X12 si apprende di difetti, vulnerabilità e stranezze già a livello di core protocol (a cui in certi casi non si è posto, o non si ritiene plausibile un rimedio non già per motivi tecnici, quanto per “il numero dei client che andrebbero modificati”)
    lascia ancor più a desiderare in confronto agli altri sistemi GUI contemporanei, da molto prima che venisse la “moda” dell’ accelerazione tramite GPU e del compositing (questa in buona parte è venuta con la tendenza da parte dei progettisti di gpu, ad unificare le pipeline 2D e 3D a livello di chip)
    una cosa che caratterizzava gli OS desktop non unix già negli anni 80 e 90 (a parte il non conformarsi, non del tutto almeno, alla monocultura unix – cosa che li avrebbe poi relegati a nicchie sempre più ristrette a causa del mancato supporto al sw “mainstream”) era il cercare di rendere il più ottimizzato e “intelligente” possibile (per l’ epoca) il ciclo di redraw possibilmente sfruttando quel “poco” (rispetto a oggi) che l’ HW metteva a disposizione per il 2D (blitting, clipping, disegno di polyline, riempimenti, ecc) con una GUI il più possibile leggera
    quello che ad esempio accomunava, se non windows, BeOS, nextstep, syllable OS, o skyOS – era una gui userspace sotto forma di un cosiddetto application server (che gestisce le finestre, l’ input, e in certi casi implementa anche i widget) in cui fin da subito confluivano accorgimenti per determinare quali aree andavano ridisegnate, applicare algoritmi back to front, clipping, trasparenza, eccetera (e se non da subito, erano implementati come ottimizzazione interna, raramente toccando la api applicativa)
    cose che X ha guadagnato solo all’ inizio del millennio (e solo con delle estensioni), molto in ritardo sui sistemi di cui sopra – e in effetti in ritardo sulle esigenze che il pubblico ne aveva…
    ma anche se vogliamo molto peggio (in modo meno efficiente ed elegante) rispetto a questi, in cui la combinazione di app server e api grafica era progettata come una singola entità dalla ridotta complessità esterna (in api e protocolli imposti ai programmi userspace)…
    e non non come un’ accozzaglia di specifiche (da XRender a XDND passando per ICCCM e gli EWMH) ed estensioni a un protocollo base (da supportare comunque, quindi con diversi code path da mantenere), notevolmente complessa e sovraingegnerizzata in rapporto a ciò che fa …

  • # 8
    goldorak
     scrive: 

    Shodanshok ha ragione.
    Molti dei motivi delle scarse prestazioni sul desktop in linux hanno a che vedere o con i driver proprietari (vedi il caso di nvidia che fornisce ottime prestazioni nel 3d ma se ne frega altamente di ottimizzare alla stessa maniera il 2d).
    L’altra causa per le scarse prestazioni sta appunto nei vari toolkits che sfruttano per motivi di compatibilita’ istruzioni “obsolete”. L’uso massiccio di codice fpu x87 fa da collo di bottiglia tremendo alle prestazioni.
    Ci sono molti livelli su cui si puo’ intervenire per migliore le prestazioni, ma l’ignoranza gigantesca delle gente tende a prendere come capo espiatorio il sistema X. Quando ce’ qualcosa che non va diamo la colpa a X. Invece di mettere mani laddove serve davvero si inventano soluzioni strampalate a problemi inesistenti.
    Per quanto vecchia sia l’architettura X, offre molte piu’ funzionalita’ rispetto a Wayland. Quindi dovremmo eliminare un sistema che funziona a favore di uno che e’ in fase di alfa, e che non avra’ mai e poi mai tutte le caratteristiche (in primis la network transparency) di X. Sembre di rivedere il casino fatto con pulseaudio. Stesso identico problema. Invece di lavorare su oss e migliorarlo si e’ andati a creare un mostro dal nome alsa sul quale poi si e’ costruito un altro mostro dal nome pulseaudio. Con la conseguenza che dopo un decennio ancora non esiste una infrastruttura audio semplice e funzionale in linux. Non si impare mai niente a quanto vedo.
    Le prestazioni di X non sono il collo di bottiglia sul desktop, le cause dei rallentamenti vanno cercati altrove. Nei drivers, nei toolkits e anche nello scheduler (che a seconda dei carichi di lavoro tende a paralizzare tutto il desktop).

  • # 9
    Emanuele Rampichini (Autore del post)
     scrive: 

    @goldorak

    Ci sono molti livelli su cui si puo’ intervenire per migliore le prestazioni, ma l’ignoranza gigantesca delle gente tende a prendere come capo espiatorio il sistema X. Quando ce’ qualcosa che non va diamo la colpa a X. Invece di mettere mani laddove serve davvero si inventano soluzioni strampalate a problemi inesistenti.

    Nell’articolo non ho scritto da nessuna parte che X sia la causa di tutti i mali del mondo e non gli ho dato colpe generiche. Però il fatto che introduca un overhead non necessario in uno scenario di utilizzo desktop è sotto gli occhi di tutti. Prendi questo articolo di Marco Martin e comprenderai di cosa si sta parlando:

    http://www.notmart.org/index.php/Software/Netbook_and_performance

    Per quanto vecchia sia l’architettura X, offre molte piu’ funzionalita’ rispetto a Wayland. Quindi dovremmo eliminare un sistema che funziona a favore di uno che e’ in fase di alfa, e che non avra’ mai e poi mai tutte le caratteristiche (in primis la network transparency) di X.

    Ma qui si sta parlando di uno scenario di utilizzo specifico, desktop + sistema di compositing. La network transparency è una bellissima feature ma quanto serve in questo scenario?

  • # 10
    Pluto
     scrive: 

    In questo articolo http://www.std.org/~msm/common/protocol.pdf
    nel capitolo 7 si dice che uno dei limiti di X è l’impacchettamento e lo spacchettamento dei messaggi.

    Come fa ad essere un limite questo?

    Mi spiego meglio:
    Se io voglio costruire un protocollo che trasmette una interfaccia
    grafica via rete, questo dovrà essere un requisito, non un limite.

  • # 11
    shodanshok
     scrive: 

    @Emanuele Rampichini

    Attenzione: l’articolo che hai linkato evidenzia una deficienza dell’implementazione lato driver dell’estensione XRender (evidentemente non è accelerata in modo corretto) o, al massimo, un problema dell’estensione XRender stessa, ma _non_ di X in se stesso. La controprova è che il rendering via software funziona correttamente.

    Capiamoci: non metto in dubbio che il tuo articolo sia interessante, né che sia sbagliato quello che dici riguardo ad X (che è lento e vecchio). Il punto è che, a mio avviso, questo non è il problema principale: l’overhead imposto dai toolkit grafici, così come la mancanza di concentrazione su un’unica acceleration architecture da sviluppare organicamente (si è passati dalla storica XAA a EXA a AIGLX a XGL, passando per NVAA di Nvidia) sono problemi molto più grossi.

    La prova è che le applicazioni native X sono velocissime sull’hardware odierno. I nostri desktop, invece, pasano attraverso mille layer di astrazione che sicuramente sono utili, ma vanno ottimizzati per bene, altrimenti si porta a rallentare tutto (si guardi l’esempio di Pango che ho portato prima, e che rendeva firefox inutilizzabile su un Celeron 1 GHz).

    Ciao.

  • # 12
    Emanuele Rampichini (Autore del post)
     scrive: 

    @shodanshok
    Mi sono dimenticato di evidenziare la frase dell’articolo che rende l’idea del problema:

    Second, if QPainter hits some code patch that aren’t directly implemented via the X11 graphics system it will have to fall back to another paint system: raster, that is totally software based, so pixmap-to-image conversion (and memory copy) is involved (and is necessary, to not actually lose features depending on what graphics system you’re on), and things slow down.

    La penalizzazione del cambio di contesto (necessario per implementare alcune feature) è tale da rendere conveniente l’utilizzo in partenza del software rendering.

    Comunque ti ringrazio per le puntuali aggiunte. Hai fatto bene ad evidenziare che per migliorare le cose si può agire su diversi livelli.

  • # 13
    shodanshok
     scrive: 

    @ Emanuele Rampichini

    Hai ragione sulle penalizzazioni del cambio di contesto: è per questo che dico che la cosa migliora sarebbe decidere quale infrastruttura di accelerazione usare e svilupparla _per bene_

    Ovviamente imbattersi in una XRender fatta via software è molto più lento che fare direttamente tutto via software…

    Speriamo che le cose migliorino :D
    Ciao.

  • # 14
    homero
     scrive: 

    “Per quanto vecchia sia l’architettura X, offre molte piu’ funzionalita’ rispetto a Wayland. Quindi dovremmo eliminare un sistema che funziona a favore di uno che e’ in fase di alfa”

    concordo in pieno quanto scritto.

    nessuno infatto ha colto il reale problema delle prestazioni di interfaccia desktop…che sono essenzialmente hardware.

    SGI risolse il problema con le openGL…ossia scrivendo librerie capaci di dialogare direttamente con l’hardware e con il kernel senza passare attracerso il desktop manager.

    questa è la strada da percorrere…tra l’altro percorsa anche da microsoft con le sue directx…

    bisogna prendere una posizione sulle specifiche hardware sulle quale un desktop manager deve girare, un’altro desktop manager general purpose astratto non serve a nessuno…

    al contrario un desktop manager che dialoga direttamente con l’hardware è la base su cui costruire il futuro.

    ci sono sistemi desktop “finti” basati su embedded linux che sono estremamente veloci e pratici da usare…senza X o altro…

    quindi la domanda giusta è:

    “il mondo desktop puo’ fare a meno di X11?”

  • # 15
    j
     scrive: 

    Per quanto vecchia sia l’architettura X, offre molte piu’ funzionalita’ rispetto a Wayland

    offre più funzionalità perchè è stato concepito partendo da assunzioni differenti, in un contesto differente, in un’ epoca differente (quindi il fatto che sia vecchia non è un dettaglio irrilevante come sembra dal tuo discorso, al contrario)

    X non solo non è stato concepito per il desktop (inteso come postazione personale con applicazioni ed elaborazioni interamente locali da parte di hw di sufficiente capacità), quando è stato concepito non esisteva nemmeno il desktop – in compenso esistevano mainframe e terminali, e utenti remoti in time sharing
    quindi, un sistema distribuito che concentrasse tutte le funzionalità in un singolo server grafico (a sua volta eseguito sul sistema che accentrava le risorse di calcolo), aveva senso (anche visto e considerato di “che” genere di grafica computerizzata si trattava – nulla a che vedere con la complessità sia strutturale -dato il numero di elementi presenti nel layout- che algoritmica -date le operazioni coinvolte per generare gradienti, smussare bordi e testo, applicare trasparenze o sfocature – di una gui odierna)

    dì’ altro canto è interessante notare come gli OS desktop di maggior rilievo che la storia ricordi, sono nati da una parte dopo X, e dall ‘altra inizialmente privi di qualsivoglia supporto di rete, ma ovviamente non di una GUI – la quale quindi era tutto meno che network transparent, e in effetti si limitava a consentire alle applicazioni in esecuzione sulla macchina di disegnare sullo schermo collegato alla stessa macchina, e consentire all’ utente seduto di fonte a questo, di interagirvi – con un overhead ridotto (anche viste e considerate le risorse di calcolo e elaborazione /visualizzazione grafica disponibili all’ epoca)
    non che questo fosse limitativo nell’ uso della macchina (anzi, era nè più nè meno quello che a logica ci si aspetta da una GUI locale) nè ha impedito a Windows, AmigaOS o BeOS di dotarsi di stack di rete in un secondo momento, quando è venuta l’ esigenza di comunicare con altri pc nel gruppo di lavoro e/o con internet
    ma a quel punto lo stack di rete veniva aggiunto senza inficiare quello grafico, nè le applicazioni locali, nè gli utenti desktop (che nel 99% dei casi della possibilità di eseguire applicazioni in remoto fanno tranquillamente a meno)

    Quindi dovremmo eliminare

    eliminare, no, quantomeno non nell’ immediato – infatti lo stesso progetto wayland si occupa di supportare X, solo facendolo girare come client wayland e non come oggetto di primo livello…

    un sistema che funziona

    a volte penso che “funziona” è un po’ una parola grossa… XD

    a favore di uno che e’ in fase di alfa

    al di là del fatto che X avrebbe dovuto essere sostituito con qualcos’ altro già da molto tempo, non si parla certo di sostituirlo integralmente con wayland, ora
    si parlava del motivo per cui quest’ ultimo è un progettino interessante (per quanto nell’ orbita di un sistema che oramai si sarà capito quanto il sottoscritto “ami”… XD)

    e che non avra’ mai e poi mai tutte le caratteristiche (in primis la network transparency) di X.

    [volgare]ma all’ utente desktop non gliene può fregare di meno della network transparency…[/volgare]

    seriamente, la network transparency è senz’ altro utile, per il remoting ad esempio, ma è una feature ortogonale e sovrapponibile, implementabile in un secondo tempo, piuttosto che un punto di partenza per il design di una gui locale – come in effetti dovrebbe far intuire il fatto che un server grafico eseguito in remoto possa sì sfruttare un eventuale gpu come acceleratore, ma non abbia bisogno di uno stack grafico locale, potendo teoricamente eseguire via sw

    ma allora la domanda diventa: perchè portarsi dietro un sistema che svolge due funzioni distinte (e al tempo stesso lasciandone fuori una invece fondamentale per la gui locale, come la gestione delle finestre), e lo fa con prestazioni intrinsecamente subottime e comunque inferiori rispetto a sistemi ottimizzati in funzione del desktop?

    Sembre di rivedere il casino fatto con pulseaudio. Stesso identico problema

    infatti anche pulseaudio soffre dello stesso problema di X, della stessa inversione di priorità in sede di scelta di feature e design
    dato un sistema PC dotato di una periferica sonora locale, l’ esigenza principale è condividerla tra le applicazioni locali per consentire a queste di mandare in uscita dell’ audio senza errori “periferica già in uso da un altro processo” questo (oltre che latenze possibilmente basse, e *funzionare*) è tutto ciò che si richiede allo stack sonoro
    eventuali stream provenienti da altre macchine in rete, possono essere riprodotti da un servizio opzionale, a sua volta client dello stack audio locale, senza bisogno di appesantire quest’ ultimo con una feature (oltre a molte altre completamente inutili, tipo il panning per seguire a seconda della posizione della finestra) inutile se non a geek, per applicazioni particolari

    Invece di lavorare su oss e migliorarlo si e’ andati a creare un mostro dal nome alsa sul quale poi si e’ costruito un altro mostro dal nome pulseaudio.

    non è assolutamente la stessa cosa
    a quanto ricordo, l’ open sound system incluso nel kernel e l’ open sound system di riferimento erano due cose alquanto scollegate già da prima – nel senso che la versione di OSS free impiegata in linux non era esattamente lo stesso codice di OSS impiegato su altri sistemi unix, se non sbaglio era una versione indietro, 2.x invece che 3
    questo, unito alle limitazioni di OSS fino alla versione 3 e ancor più di OSS per come implementato in linux, avevano alimentato un senso di rivalsa verso OSS “ad interim” e contribuito alla sua fama di sistema audio scadente
    da cui la riprogettazione totale dello stack sonoro in occasione del cambio di licenza di OSS all’ uscita della versione 4 (che risolveva il problema sostanziale delle versioni precedenti -impossibilità di condividere la periferica- esponendo una api consistente con la filosofia unix della semplicità) – se lo scopo fosse stato solo superare le limitazioni dell’ implementazione di linux, si sarebbe potuto riscrivere solo quella, prendendo OSS4 come riferimento con cui restare compatibile (anche perchè OSS restava l’ api sonora sugli altri sistemi unix)

    il fatto che si sia inseguita una soluzione del tutto nuova, peraltro notevolmente complessa eppure incompleta (giacchè si rende ancora necessario un server sonoro per la condivisione del device) quindi se si sono prese il più possibile le distanze da OSSv4, è stato in buona parte dettato da motivazioni politiche e di principio, che si è poi voluto mascherare con argomentazioni di carattere tecnico

    Le prestazioni di X non sono il collo di bottiglia sul desktop, le cause dei rallentamenti vanno cercati altrove. Nei drivers

    dare la colpa ai drivers è comodo, permette di scaricare la responsabilità sui produttori di hw (perchè non contribuiscono codice di qualità sufficiente, non testano, non pubblicano le specifiche, …), e di fare a meno di ammettere che in effetti i problemi sono sistemici…

    la verità che non si vuole vedere è che sistemi che pure non hanno mai potuto contare sul MillionProgrammersArmy(tm) su cui invece ha potuto e può contare linux, erano desktop più reattivi di quanto non sia mai stato linux, drivers o non drivers – semplicemente perchè potevano contare su un design migliore

    domanda: a parità di risultati, è più efficiente un sistema che richiede round trips, ed elaborazione ad ogni passaggio in una transazione (invocazione di procedura da parte di un client o gestione di un evento), o uno che non ne richiede?

    nei toolkits

    se il problema è la mancanza di reattività, toolkit e librerie con la loro pesantezza possono aggravarlo, ma non ne sono certo l’ unica causa
    (e d’ altra parte, sull’ overhead introdotto dalla libreria -entità autocontenuta- si può intervenire ottimizzando quest’ ultima, su quello indotto da protocolli system wise, no -o comunque con molta minore efficacia – a meno di non rivedere radicalmente tali protocolli)

    e anche nello scheduler (che a seconda dei carichi di lavoro tende a paralizzare tutto il desktop).

    idem come sopra

  • # 16
    TheKaneB
     scrive: 

    standing ovation per j

  • # 17
    j
     scrive: 

    Pluto

    In questo articolo http://www.std.org/~msm/common/protocol.pdf
    nel capitolo 7 si dice che uno dei limiti di X è l’impacchettamento e lo spacchettamento dei messaggi.

    Come fa ad essere un limite questo?

    è un limite nel senso che è meno efficiente di sistemi di chiamata di procedura locale quali quelli implementati in altri sistemi, come windows ( che ha le LPC/QuickLPC) o SunOS (che se non erro quando quel paper è stato scritto aveva già le Doors)

    Mi spiego meglio:
    Se io voglio costruire un protocollo che trasmette una interfaccia
    grafica via rete, questo dovrà essere un requisito, non un limite.

    guardala in quest’ ottica:
    per trasmettere un’ interfaccia grafica via rete devi per forza serializzare e deserializzare (marshaling), non c’è uscita

    ora, siccome il sistema operativo ha tutto quello che serve (accesso completo alle pagine di memoria e alla gestione dei processi, meccanismi di preemption e ripresa di processi) volendo si può prevedere un meccanismo di control transfer che permetta di passare da un processo client a uno server in un’ invocazione di funzione, senza dover fare marshaling di argomenti (+ nome) e risultati della funzione
    si può ad esempio (come in LRPC , che si aggiunge a quelli prima citati) sfruttare stack condivisi per passare gli argomenti, e usare il kernel come tramite per l’ invocazione diretta (analogamente a quanto avviene per i signal), nello spazio del server (che non avrà più bisogno di looppare sulla ricezione di pacchetti da deserializzare per capire quale funzione eseguire), del metodo richiesto dal client (che il server avrà in precedenza dichiarato)

    quindi almeno in linea di principio una via di uscita dal marshaling esiste, per processi client e server locali, cioè sulla stessa macchina … ma questo è esattamente il caso qualora la GUI sia prima di tutto il modo in cui l’ OS multiplexa la gpu della macchina e lo spazio sul display collegato a questa tra le applicazioni eseguite localmente, più che un servizio di rete…

    imporre alle applicazioni di comunicare con il server grafico (ma è un discorso di ipc/rpc che vale in generale) facendo marshaling anche nel caso locale, è inefficiente
    farlo quando esistano i mezzi (accorgimenti ottimizzati) per evitarlo, o evitare di implementarli quando vi siano le basi lato kernel per farlo, è… stupido

  • # 18
    j
     scrive: 

    @ TheKaneB: grazie :)) ;)

  • # 19
    shodanshok
     scrive: 

    @ J

    Personalmente condivido le tue osservazioni su X e sulla sua inefficienza generale, in quanto nato per supportare nativamente features che a un utente desktop non servono un granchè.

    Il punto, però, è che questo discorso ha la sua validità se si parla di macchine di 20-15 anni fa (486, Pentium) ma non con sistemi moderni. Su macchine recenti (indendo dell’ultimo decennio), le inefficienze del protocollo X (perchè poi della qualità delle implementazioni dello stesso, XFree prima e X.org poi, si potrebbe discutere) sono piuttosto irrilevanti.

    Ciò che invece peggiora l’esperienza d’uso sono i lag introdotti principalmente da:
    – acceleration architecture introdotte di fretta e furia ma mai realmente integrate in _tutti_ i driver (come dicevo sopra, si è passato da XAA a KDRIVE a EXA a AIGLX a XGL e via dicendo)
    – driver subottimali (i driver closed source di ATI/Nvidia non sono citati a caso: nel rendering di alcune primitive 2D, così come del test con subpixel antialiasing, sono, o per lo meno erano fino a poco fa, molto più lenti dei corrispettivi driver open)
    – soprattutto, toolkit grafici eccessivamente complessi.

    Elaboro un po’ sull’ultimo punto: al giorno d’oggi, il toolkit grafico più diffuso (GTK) risulta sicuramente sovraingengerizzato e piuttosto inefficiente. A peggiorare le cose, dalle GTK 2.8 si sta progressivamente usando Cairo come backend grafico predefinito per molti widget. Cairo è una libreria di grafica vettoriale e, quindi, è piuttosto pesante dal punto divista della CPU (anche se i risultati sono notevoli) e, in particolare, richiede una FPU x87 veloce. Si, X87: le SSE/2/3 sono usate solo in misura marginale. Ciliagina sulla torta, il sistema di rendering dei font predefinito delle GTK, Pango, è molto evoluto (può rappresentare fonts di qualunque lingua) ma a sua volta comporta un certo carico CPU (addirittura alcuni anni fa, quando l’ottimizzazione di questo componente era molto limitata, Firefox era lento nel rendering di pagine con molto testo anche su quello che era il mio sistema principale, un Athlon XP 2800+).

    Il peso complessivo di tutti questi passaggi non è piccolo, anzi, nella maggioranza dei casi eclissa i lag attribuibili ad X. Se qualcuno è interessato posso ripetere la profilazione del sistema mentre eseguo alcune semplici operazioni di redraw del video e postare i risultati. Comunque, basta una ricerca su google con GTK/Cairo/Pango + slow performance per rendersi conto di quanto fosse sentito il bisogno di semplificare/velocizzare un po’ il tutto (parlo al passato perchè da quanto ricordo le GTK 3.0 dovrebbero essere un passo avanti in questa direzione).

    Un’ultima nota: la scelta del window manager, tradizionalmente secondaria da un punto di vista delle pure prestazioni velocistiche, ha ora grande peso: da quanto il window manager integra o è strettamente affiancato da un compositor, molte operazioni di redraw possono essere evitate. Perchè? Perchè in genere il compositor stocca i dati delle finestre in buffer off-screen e, quando una finestra si sovrappone alla prima, non c’è bisogno di eseguire il redraw, ma solo di copiare un’area di memoria da una parte all’altra. In realtà una cosa del genere lo fa anche il backingstore integrato in X ma, a causa di driver non troppo compatibili, spesso l’abilitazione del backingstore integrato causa artefatti (soprattutto nella modalità whenmapped).

    Ciao.

  • # 20
    homero
     scrive: 

    x J

    le feuture che citi non c’entrano un bel tubo sulla reattività…
    windowsXP è riuscito a mantenere una gestione del desktop efficiente grazie sopratutto alle directX e al loro supporto hardware…

    pertanto qualunque desktop manager dovesse essere il futuro di linux non puo’ prescindere da una libreria di gestione dell’hardware efficente ed efficace e sopratutto standard…

    scrivere da zero un nuovo X11-semplificato significa non soltanto e non necessariamente limitare le funzioni, ma essenzialmente integrarsi con un modello hardware…le alternative proposte nell’articolo questo non lo mettono in risalto…anzi mostrano un progetto simile a quanto progettato 20 anni fa con X11…ed in quanto tale inutile…

    il futuro del desktop è essenzialmente un nuovo modo di approcciarsi all’hardware specialmente in virtu’ delle nuove cpu che integrano una gpu al loro interno…

  • # 21
    goldorak
     scrive: 

    A sentire molti in questa discussione, voi riscrivereste daccapo l’80% di una applicazione per ottenere un piccolo miglioramento prestazionale allorche’ il profiler vi dice esplicitamente che l’80% del tempo di esecuzione viene trascorso in 20% del codice.
    Non stupisce allora dei disastri che si riscontrano nel desktop linux. ^_^ Ottimizzare dove serve.

    Io applaudo shodanshok che e’ l’unico che vede la foresta, tutti gli altri vedono i singoli alberi. X e’ inefficiente, in termini assoluti si. Con hardware moderno no, e’ come eseguire xp su hardware del 2010. Vola, invece su hardware del 2001 andava cosi’ cosi’. I colli di bottiglia stanno altrove ed e’ li’ che il lavoro deve concentrarsi.

  • # 22
    Cesare Di Mauro
     scrive: 

    Ma di Linux non si vanta il fatto che possa girare anche su PC datati, o in generale su hardware obsoleto (con poche risorse)? Lì X11 farebbe o no la differenza? E se sì, perché non eliminarlo in favore di una soluzione più moderna ed efficiente? Da portare poi anche nei supercomputer odierni che hanno potenza di calcolo da vendere…

  • # 23
    floriano
     scrive: 

    su un p3 733mhz (e non solo) con 384mb di ram le prestazioni di xp sono superiori a quelle di qualunque linux abbia provato (anche la vecchia mandrake 9.2)

    solo la dynbebolic (che non usava strati oltre al server x) dava risultati interessanti.

  • # 24
    Pluto
     scrive: 

    @j

    Grazie di avermi risposto, pensavo di aver fatto una domanda stupita.

    Sono perfettamente d’accordo nel dire che l’archittetura di X è subottima perché è stato pensato per un’epoca diversa dall’attuale
    e che il marshalling/unmarshalling è un processo inutile e pesante.

    D’altro canto mi piacerebbe molto che i produttori di GPU mettessero a disposizione per lo meno le specifiche dei propri dispositivi, in modo da avere (in futuro) un confronto tra diverse soluzioni che sostituiranno X alla pari con altri sistemi (se mai esisteranno).

    Se non lo volgliono fare per le ultime novità del loro listino almeno lo possono fare per qualche scheda del loro recente passato, così salvano i loro investimenti in R&D.

  • # 25
    shodanshok
     scrive: 

    @ Cesare di Mauro

    Diciamo che la possibilità di far girare Linux anche su sistemi datati è stata abbondantemente mitizzata. Il punto è: cosa intendiamo con Linux? Il kernel? Se si, questo è adattabilissimo: è usato con successo addirittura su alcuni distributori automatici con risorse hardware limitatissime.

    Ma se parliamo di Linux come “distribuzione di un s.o.” le cose non sono più così rosee: anni fa avevo un P3 500 e Win2000 girava decisamente meglio di Red Hat 7.2. Ma il problema non era Linux nella sua interezza. Era la pesantezza degli ambienti grafici (in particolare, GNOME era troppo affamato di memoria, costringendo a usare spesso lo swap): installato un wm più leggero (WindowsMaker/Fluxbox), la macchina era rinata.

    Alla tua domanda specifica (“Lì X11 farebbe o no la differenza?”) la risposta è ni: se parliamo di hardware non proprio arcaico e in grado di elaborare efficientemente codice a 32 bit (diciamo da PPro / K6 in poi), sono convito che l’overhead imposto dal protocollo X (ripeto: protocollo, non implementazione XFREE/Xorg) non prende che alcuni punti percentuali di CPU. Al contrario, tutto il rendering fatto via softare dai vari toolkit grafici (GTK in primisi), ucciderebbe le prestazioni grafiche della macchina.

    Anche perchè, per quanto X sia utilizzabile via rete, sono ormai anni che la comunicazione tra xclient/xserver che risiedono sulla stessa macchina avviene tramite unix socket e non più via socket di rete. Questo contribuisce a minimizzare eventuali problemi di lag.

    Riporto nuovamente la mia esperienza: su un Celeron @ 1 GHz, la versione di Firefox inclusa con Debian era praticamente inutilizzabile. A causa di cosa? X? No! A causa di Pango: disabilitato questo, lo scrolling era diventato 3/4 volte più veloce.

    Alla luce di questo, ciò che è davvero importate è sistemare i toolit grafici e i vari driver, _poi_ avrà senza concentrarsi sul protocollo X. Per fare un esempio, sul sistema dal quale scrivo (Dell Latitude D6410 con i5 520 e grafica Intel HD integrata), abilitando gli effetti grafici KDE è lentissimo e anche GNOME ogni tanto rallenta un po’ nel rendering degli oggetti. La colpa è di X? No, di Intel: le prestazioni 3D dei suoi driver open sono 1/5 di quelle dei driver di Windows. E considera che i driver Intel sono probabilmente _i migliori_ driver open disponibili.

    Ciao.

  • # 26
    shodanshok
     scrive: 

    @ Homero

    Ciao, per il disegno delle normali finestre bidimensionali, Windows XP _non_ usa le DirectX, bensì le classiche GDI+.

    Il fatto che Windows XP mantenga, come dici, “un desktop efficiente” risula primariamente dell’ottimo supporto che chipset e driver grafici hanno fornito alle raster ops e ad altre caratteristiche indicate delle GDI/GDI+

    Inoltre, a livello di effetti grafici predefiniti, Windows XP è piuttosto povero dal punto di vista odierno (occhio: per me è un pregio!). E’ per questi motivi che è più difficile scorgere problemi di redraw.

    Tuttavia, prova a caricare qualche mod pack per Windows XP e ti accorgerai che, a fronte di una grafica più elaborata, corrisponde una lentezza sensibilmente maggiore rispetto a quanto ottenibile di default.

    Ciao.

  • # 27
    homero
     scrive: 

    comunque sia dei punti fermi credo che siano stati raggiunti:

    1) X11 non è il miglior windows manager per desktop ma non è tanto peggio di altri

    2) decidere su quale configurazione hardware minima far girare un windows manager è il punto di partenza da cui iniziare lo sviluppo di un nuovo sistema di gestione finestre per desktop

    3) i driver che gestiscono l’hardware video sono alla base di qualunque sistema desktop efficace, apple ha già da 10 anni indirizzato il suo sistema in questa direzione, linux invece vive ancora una condizione magmatica dei vari driver video…

    un modello potrebbere essere quello di MacOSX, ma personalmente guarderei ancora oltre, con un windows manager che gira direttamente sulla GPU…ma questa potrebbe essere fantascienza…

  • # 28
    goldorak
     scrive: 

    @ homero : non hai ben chiara la differenza tra l’X-server, un windows manager e un (presumo io) desktop environment.
    L’X-server da solo non gestisce finestre. E solo in grado di riservare una porzione dello schermo dove la tua applicazione indirizzera’ il suo output. In quanto tale le applicazioni che sfruttando l’X-server da solo sono molto limitate.
    Astraendo leggermente si passa al livello dei windows managers, nella cui categoria rientrano software come windows enlightenment, o windows maker, o afterstep o gnustep etc… Questi sono software che forniscono alle applicazioni il concetto di finestra come la intendiamo nel senso moderno del termine, windows bar, possiblita’ di spostare la finestra sul desktop, aprire, chiudere, etc…
    Sono in effetti picolissime “shell” che gestiscono le finestre delle applicazioni.
    Salendo ancora piu’ su sulla scala delle astrazioni e quindi della pesantezza software ci sono infine i desktop environment veri maccigni (e il piu’ grande diffetto copiato dal mondo windows). Le applicazioni gnome o kde sono “integrate” nel loro rispetto ambiente ma si possono anche eseguire senza alcun problema in un windows manager leggero (togliendo quindi il desktop environment).

    Puoi’ sembrare strano ma ce’ gente che apprezza la leggerezza e velocita’ di un windows manager puro. Senza portarsi dietro il peso morto di un desktop environment. E questo senza rinunciare ad alcuna applicazione che gira su linux. ^_^

  • # 29
    TheKaneB
     scrive: 

    @goldorak: confermo. Con un Enlightenment E17, oppure FluxBox ottengo una reattività veramente soddisfacente anche su computer molto limitati (netbook cinesi e computer di 10 anni fa). Il prezzo da pagare è la povertà dell’interfaccia utente. Per un utente medio è sicuramente meglio usare Gnome o KDE, ma se sei un SysAdmin o un programmatore o semplicemente un enthusiast, allora forse vale la pena sforzarsi di usare un sistema minimale (ovviamente se hai un computer obsoleto, altrimenti vai tranquillo con KDE).

  • # 30
    homero
     scrive: 

    x goldorak

    grazie per il chiarimento, quanto hai scritto mi era del tutto oscuro…

  • # 31
    dvd
     scrive: 

    lupus in fabula
    http://www.markshuttleworth.com/archives/551
    Mr. Ubuntu ha annunciato che in un anno passerà da Xorg a wayland

  • # 32
    Cesare Di Mauro
     scrive: 

    @shodanshok: le motivazioni che hai esposto sono chiarissime. Quando parlo di Linux mi riferisco ovviamente alle distro; sappiamo bene che Linux è il solo kernel, ma nell’accezione comune è diventato sinonimo di intero s.o., e il contesto si riferiva a questo.

    Riguardo ai PC datati, anche qualche punto percentuale può fare la differenza. Se prendi AROS, anche su sistemi in cui utilizza esclusivamente la modalità VESA (e quindi rendering interamente software; zero accelerazione hardware) ha una reattività impressionante (oltre a un consumo di risorse che definire infimo è fargli un complimento). Non avrà tutti gli effetti speciali dei s.o. moderni, ma certamente la GUI non è minimale e le applicazioni che fanno uso di toolkit come MUI sono stupende e visivamente molto appaganti.

    Detto ciò, rimango dell’idea che X11 sia un mostro da eliminare. Per le problematiche che voleva risolvere si può far uso di soluzioni dedicate, senza appesantire il caso comune con uno strato software che fa uso di un protocollo di comunicazione, che trovo assolutamente aberrante allo scopo. Ma di questo ne ha parlato ampiamente j.

    Poi che ci siano problemi di altra natura è evidente, ma a questo punto e vista la situazione chissà quando verranno risolti. Nel frattempo se c’è gente che porta avanti progetti (moderni e più efficienti) alternativi a X11… ben venga, no? ;)

  • # 33
    shodanshok
     scrive: 

    @ Cesare
    Capisco il tuo punto di vista, ma sono d’accordo solo in parte.

    Anni fa, usai per diverso tempo X + Fluxbox/IceWM su un PPro200 con 64 MB di RAM e scheda video Trio64V+ (driver VESA). Il sistema era perfettamente usabile e discretamente. Il motivo per cui dovetti ricorrere a un window manager leggero non era legato all’overhead di X, ma al fatto che con soli 64 MB di RAM GNOME/KDE sarebbero andati al rilento.

    Il punto è: ci preoccupiamo di un overhead che era trascurabile addirittura un un PPro 200? Forse questo era un problema all’epoca dei 486, ma non ora e né 10 anni fa.

    Sviluppare qualcosa di alternativo a X11 è un bene? In senso generico, sì: se è possibile eliminare anche questo leggero overhead, ben venga. Tuttavia, sono uno di quelli che pensa che eccessiva frammentazione delle risorse (intese come programmatori) sia un danno. Si vuole migliorare l’esperienza desktop? Benissimo, si riveda il modo in cui i tookit lavorano. Si vuole ottimizzare tutto il sistema? Si aiuti a migliorare le libc, che fanno ancora un uso limitato delle istruzioni vettoriali.

    In altre parole: perchè concentrarsi sul software che occupa l’1% delle risorse hardware odierne e non, invece, di quello che ne prende il 90%?

    Ovviamente questa è la mia, discutibilissima, opinione personale… :)

    Ciao.

  • # 34
    guiodic
     scrive: 

    Articolo interessante e commenti interessanti.

    Non concordo affatto però con affermazioni del tipo:

    offre più funzionalità perchè è stato concepito partendo da assunzioni differenti, in un contesto differente, in un’ epoca differente (quindi il fatto che sia vecchia non è un dettaglio irrilevante come sembra dal tuo discorso, al contrario)

    L’epoca a cui ti riferisci è quella in cui si diffondevano le reti e Internet (o il suo antenato). Ora si parla di cloud computing come se fosse una novità, quando invece Unix è sempre stato “cloud”. X è pronto per il cloud, wayland no. Eliminare X è come darsi la zappa sui piedi per il futuro. Ottieni un miglioramento del tutto trascurabile se non accompagnato da nuovi backend opengl accelerati per gtk+cairo, in compenso perdi la trasparenza di rete che è il *futuro* non il passato.

    Questa si chiama miopia.

  • # 35
    guiodic
     scrive: 

    sono ormai anni che la comunicazione tra xclient/xserver che risiedono sulla stessa macchina avviene tramite unix socket e non più via socket di rete.

    non credo sia mai avvenuto via socket di rete sulla stessa macchina. Comunque sia da 20 anni (non da ieri) c’è mit-shm.

    Questo ancora una volta per smitizzare ancora una volta le cose che si sentono su Xorg…

  • # 36
    shodanshok
     scrive: 

    @ guiodic

    Nel passato ci sono state architetture che si connettevano a X tramite l’interfaccia di loopback. Anche per questo motivo, n passato l’ottimizzazione della loopback è stato un argomento abbastanza importante (vedi capitolo 2 o 3 di TCP/IP Illustrated).

    Poi certo c’è SHM, ma non era usata su tutti i sistemi POSIX.

    Nei miei commenti, ho difeso X perchè credo che i veri problemi, anche in ambito desktop, siano altrove. Tuttavia, pensare di basare un’architettura cloud sul puro protocollo X è sbagliato: per quanto funzioni, su normali link WAN è troppo lento (risente troppo della latenza, aka RTT). Un’ottima soluzione è invece quella che vede X + NX: la uso con soddisfazione su diversi clienti e anche loro sono molto contenti delle prestazioni che hanno (pensa che alcuni usavano Cygwin+Xwin in sessione SSH, senza nessuna compressione).

    Ciao.

  • # 37
    j
     scrive: 

    guiodic

    L’epoca a cui ti riferisci è quella in cui si diffondevano le reti e Internet (o il suo antenato). Ora si parla di cloud computing come se fosse una novità,

    primo: chi è che parla di cloud come se fosse una novità? non certamente il sottoscritto, che in effetti vi ha visto un esempio pressochè perfetto e archetipale di ricorso storico – più probabilmente il marketing e i media, che hanno un non velato interesse a creare hype e convincere il pubblico ad abbracciarlo (cosa che in certi ambiti e per certe persone resta la più grossa insensatezza che si potrebbe fare)
    secondo: su un dispositivo dotato di uno schermo connesso localmente di fronte al quale l’ utente si pone (quindi qualunque cosa dalla workstation allo smartwatch passando per netbook e telefonino – non necessariamente smartphone), ha bisogno di uno stack grafico locale
    senza uno stack grafico locale quale che sia non sarebbe possibile neanche mostrare sul display i risultati di elaborazioni, o le schermate di applicazioni, eseguite in remoto, nel caso di un client cloud

    questo dovrebbe rendere chiaro il principio di base che pensavo fosse implicito anche nel mio post precedente: stack grafico locale e stack di networking (con tutto quello che vi si appoggia, dal cloud al remote desktop) sono due entità logicamente distinte
    su unix si è creata una commistione violando il principio di ortogonalità perchè l’ esigenza era prototipare una gui distribuita – che come cerco di far capire, non è il modo più logico e corretto di creare una gui desktop, perchè il modo più logico e corretto è strutturarla separando le funzionalità per dominio di appartenenza

    quando invece Unix è sempre stato “cloud”.

    ma unix, facci caso, è anche sempre stato additato come tipico sistema “non-desktop” per vari motivi – tra cui proprio strutturazione e prestazioni intrinseche della sua “GUI”…

    X è pronto per il cloud, wayland no.

    ma non è nemmeno necessario che lo sia, visto che si assume responsabilità diverse a un livello logico diverso da quello in cui gireranno le applicazioni cloud – ed anche perchè è complementare ai componenti che le faranno girare …
    domanda: tu ti aspetti che DWM su windows o il quartz compositor su osx siano “pronti per il cloud”? no vero?

    Eliminare X è come darsi la zappa sui piedi per il futuro.

    se avessi letto sia l’ articolo di ER sia i miei post precedenti avresti visto che l’ idea non è eliminare X in assoluto, ma eliminarlo dal main loop locale
    renderlo un servizio opzionale a sua volta client dello stack grafico locale (oltre che quello di rete)
    quindi affrancare lo stack grafico locale da un particolare protocollo di remoting – cosa che renderebbe possibile, oltre a ottimizzare la gui per il caso locale, anche impiegare servizi (e protocolli) di remoting alternativi a X11 (vedi VNc, RDP…) in modo paritetico, quindi più efficiente
    quindi non mi pare darsi la zappa sui piedi, tutt’ altro…

    Ottieni un miglioramento del tutto trascurabile se non accompagnato da nuovi backend opengl accelerati per gtk+cairo>

    personalmente eliminerei anche cairo in favore di una libreria standard come openVG, ma per quello presumo occorrerà tempo…

    in compenso perdi la trasparenza di rete che è il *futuro* non il passato.

    può darsi che il futuro sia il cloud, ma un’ applicazione cloud non può prescindere da un (thin) client capace di visualizzarla, quindi dotato di uno stack locale
    anche perchè nel cloud si parla di applicazioni come web application con cui interagire via browser, ma un browser web è un’ aapplicazione desktop locale, l’ applicazione desktop per antonomasia in effetti
    in questo contesto la network transparency dello stack grafico oltre a essere una chimera, (comunque viene fatto un controllo a runtime per determinare se l’ applicazione è eseguita localmente, e si usano code path differenti nei due casi), è in effetti superflua
    quindi progettare una gui del 2010 ritenendola necessaria vuol dire partire da una mentalità che prevede non se ne possa fare a meno solo perchè “esiste”, quindi restare attaccati al passato…

    Questa si chiama miopia.

    no, si chiama cercare di progettare sw in base a criteri sensati

  • # 38
    j
     scrive: 

    shodanshok

    Il punto è: ci preoccupiamo di un overhead che era trascurabile addirittura un un PPro 200? Forse questo era un problema all’epoca dei 486, ma non ora e né 10 anni fa.

    non è questione che sia trascurabile o meno…
    a parte la mia personale convinzione che lo spreco di cicli macchina sia giustificato solo qualora il lavoro svolto sia effettivamente maggiore ( e non come in questo caso, in cui si fanno esattamente le stesse cose di altri sistemi grafici – ma con dell’ overhead dato dalla ripartizione delle responsabilità e dalla comunicazione che ne consegue) e la mia avversione viscerale per il sw non ottimizzato a livello strutturale e algoritmico – forse dovuta all’ essermi affacciato all’ informatica in tempi in cui tutto andava alla grande nonostante la scarsità (relativa) delle risorse, perchè gli sviluppatori ancora applicavano il “principio di frugalità”
    a parte ciò dicevo, il problema non è il solo overhead, il problema è anche l’ elevata -e in crescita, e non si sa per quanto ancora- complessità strutturale, e il peso che questa pone sulle spalle degli sviluppatori – non a caso c’è un detto che recita “quello che non c’è non si può rompere” …

  • # 39
    shodanshok
     scrive: 

    @ J
    Se parliamo della difficoltà oggettiva di mantenere una codebase così complessa, non posso che essere d’accordo. Anzi, direi che il problema è riconosciuto dagli stessi sviluppatori di X.org, che alcuni anni fa anno “spezzato” il server in diversi moduli compilabili e installabili separatamente (mi pare da X.org 6.8).

    Riguardo alle risorse occupate, anche io sono avverso allo spreco di risorse (ho iniziato su un C64 e di cicli da buttare non ce n’erano), tuttavia in questo caso mi pare che non abbia troppo senso concentrarsi su X quando ci sono componenti che “bruciano” N volte più CPU (vedi gli esempio che postavo sopra).

    Lo ribadisco: non voglio sostenere che X sia elegante nè che sia la migliore soluzione possibile per la network transparency (vedi protocollo RDP). Voglio solo sottolineare che, se tutto questo lavoro viene fatto in nome di un desktop più veloce, bhe, c’è da correggere prima ben altro software…

    Ciao.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.