linux user group brescia

On Mon, Sep 23, 2002 at 01:16:46PM +0200, Bauno wrote:
> 
> On Monday 23 September 2002 12:24, marco ghidinelli wrote:
> 
> > > E` vero fino ad un certo punto. Certo se usi twm il sistema ?
> > > leggerissimo. X? la pesantezza di Gnome e KDE dipende anche da XFree:
> > > che ha un toolkit vecchio di decenni (provate a lanciare xedit),
> >
> > quello e' l'XtoolKit (libXt) che oramai non viene piu' utilizzata da
> > nessuno, a parte xedit, xeditres, xman, twm, xmh e tutta quella serie di
> > programmi "vecchia".
> 
> E io che ho detto, scusa? Ma allora ? vero quanto si dice, che rispondi alle 
> e-mail senza leggerle? :-]

ehm... sei tu che dici che la pesantezza di gnome dipende anche da xfree,
che ha (xfree) un toolkit vecchio di decenni - e poi citi xedit, un
programma scritto con l'xtoolkit. 

l'esistenza o meno di libXt non pregiudica le prestazioni di X.

> > > ormai inutilizzabile a causa
> > > della sua obsolescenza. Quindi la programmazione di X ? in pratica la
> > > programmazione di un toolikit che a sua volta si appoggia a un altro
> > > toolkit che a sua volta rif? da zero i widget di X. Non il massimo in
> > > termini di efficienza.
> >
> > bauno, mi spiace dirtelo ma stai confondendo un po' i toolkit.
> 
> No. Sei tu che non hai capito ci? che ho scritto (dubito persino che tu lo 
> abbia letto). Sintentizzandolo, era che X non fornisce ormai + niente di 
> utilizzabile,

allora ho capito giusto: scusa bauno, ma non mi sembra che X non fornisca
nulla di utile, anzi. leggendo dalla mia directory /usr/X11R6/lib trovo
libdps 
libGL
libFS
libICE
libSM
libX11
libXaw		obsoleto
libXext
libXfont
libXft
libXinerama
libXi
libxkb*
libXmu
libXp
libXrandr
libXrender
libxrx
libXss
libXt		obsoleto
libXtst
libXv

mi sembra che la tua frase "X non fornisce oramai + niente di utilizzabile"
sia quantomeno discutibile, vero?
> e che sono stati aggiunti vari layer di astrazione che 
> rifanno widget, librerie, protocolli di comunicazione, etc e che hanno 
> comportato frammentazione, duplicazione e perdita di efficienza. Cosa che 
> anche tu confermi, ma dando l'impressione di contraddirmi. 

quando dici "widget rifatti" sono d'accordo perche Xt era da rifare perche'
faceva proprio schifo

librerie rifatte? per esempio?

protocolli di comunicazione? (a parte l'xprotocol che altri protocolli di
comunicazione ci sono?)

> > sono d'accordo che il passaggio attraverso l'Xprotocol sia un
> > rallentamento che pochi utilizzano. ma e' anche vero che questo
> > rallentamento lo potevi notare su un 486, ma non su una
> > architettura^H^H^H^H^H^H^H cpu odierna.
> 
> Falso. Confronta la reattivit? dell'interfaccia sullo stesso PC con Windows 
> e Linux. Non c'? paragone...

ribadisco, non vedo grosse differenze.

> > > Infine, la stratificazione ? ormai eccessiva: per aggiungere le moderne
> > > tecnologie si sono accumulati layer su layer (SDL, OpenGL, glx, Mesa,
> > > dri, etc...) che oltre a generare, in alcuni casi, un autentico casino,
> > > non hanno quelle caratteristiche di efficienza richieste dalle
> > > applicazioni grafiche.
> >
> > forse non hai mai guardato l'architettura dri...
> 
> X favore, Ghido, non difendere l'indifendibile, dri ? il classico "hack" 
> inserito x sopperire ad altre carenze architetturali.

?? dri e' inserito solo per scavalcare il protocollo X per applicazioni 3d,
e non mi sembra che metta a nudo grandi carenze architetturali...

anzi, il fatto che il sistema sia architetturato verticalmente e non
orizzontalmente come windows e' un punto a favore di x, e non contro.

> Utah-glx ? almeno un 
> po' + pulito dal punto di vista concettuale.

non lo conosco.

> E NVidia propone una soluzione 
> proprietaria (ovviamente deprecata dalla comunit?) che x?, casualmente, ha 
> prestazioni notevoli (libGL.so "ad hoc").

anche il dri ha la sua libGL.so ad hoc, tanto per dire...

> > libgl libglu e libglut sono tali e quali anche sotto windows, non vedo
> > che differenze ci siano dal punto di vista teorico.
> 
> E poi come si interfacciano all'hardware? XFree dev'essere compilato con 
> delle modifiche specifiche x il dri, devi caricare il modulo dri in X e nel 
> kernel. 'na meraviglia...

se vuoi lo compili statico nel kernel. puo' essere meglio?

allora per far muovere un mouse usb devi caricare il driver ImPS/2 in x e
il modulo usbcore nel kernel.... 'na meraviglia.

> > > Ci? che servirebbe ? un motore grafico con delle API comprensibili,
> >
> > le uniche api che mi sia studiato a suo tempo sono quelle della Xlib e
> > quelle gtk. e mi sembrano comprensibili.
> 
> E a me non sembrano API di X. Sono un'astrazione che deve comunque fare i 
> conti (ovviamente) di ci? che ha sotto, dei cui limiti abbiamo gi? parlato.

i famosi limiti che tu citi ma che io in definitiva non sono ancora
riuscito a capire.

so' di essere un po' tardo...

> > > e
> > > l'integrazione (integrazione, non aggiunta) di quelle tecnologie (3D
> > > etc..) ormai diventate irrinunciabili su un desktop.
> >
> > stai dicendo che sotto windows ti trovi delle chiamate grafiche tipo:
> > questa finestrta e' semitrasparente senza che tu abbia installato le
> > librerie opengl?
> 
> Esattamente. L'opacit? delle finestre ? prevista dalle api di Windows.

cioe' io apro una finestra e tra i parametri di apertura di una finestra
trovo anche il valore da associare all'alpha channel?

> E 
> l'accelerazione "3D" viene utilizzata nativamente anche dalle API non 
> opengl/directX, cosa che non mi risulta avvenga in X...
> 
> > questo e' accaduto in passato tra gtk e gnome, adesso le 2 architetture
> > sembrano abbastanza stabilizzate, anche se viaggiano parallelamente a
> > causa di differenze iniziali tecniche e politiche che hanno di fatto
> > creato un 'muro' tra le due parti..
> 
> E ti sembra poco! Comunque ribadisco, Gnome e KDE risentono dei limiti di 
> X...

di nuovo i famosi limiti...

> > > Si pu? fare,
> > > guardare OS-X di Apple x credere.
> >
> > non ho provato a lanciare xdpyinfo su un mac, ma penso di sapere cosa mi
> > tornera' indietro...
> 
> Cosa? Sentiamo...

ho chiesto a mio amico, quando mi risponde ti dico ..

-- 
BOFH excuse #168:

le0: no carrier: transceiver cable problem?