Tadde
08-07-2003, 19:06
Siccome la scelta server-client non è la più efficiente per un uso desktop, mi chiedevo se esistessero progetti differenti da XFree86 per Linux.
Ne sapete qualcosa?
Ne sapete qualcosa?
View Full Version : Sistema grafico Linux
Ikitt_Claw
08-07-2003, 19:10
Originally posted by "Tadde"
Siccome la scelta server-client non è la più efficiente per un uso desktop,
Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server
mi chiedevo se esistessero progetti differenti da XFree86 per Linux.
Ne sapete qualcosa?
Ci sono un po` di tentativi, ma quando va bene stanno in planning stage.
Si parlava di berlin tempo fa, non so come sia andata avanti la vcosa.
Poi ci sono un po` di port di GTK/QT su framebuffer.
Siccome la scelta server-client non è la più efficiente per un uso desktop,
Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server
mi chiedevo se esistessero progetti differenti da XFree86 per Linux.
Ne sapete qualcosa?
Ci sono un po` di tentativi, ma quando va bene stanno in planning stage.
Si parlava di berlin tempo fa, non so come sia andata avanti la vcosa.
Poi ci sono un po` di port di GTK/QT su framebuffer.
Tadde
08-07-2003, 19:14
Originally posted by "Ikitt_Claw"
Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server
Penso anch'io che sia tutto accettabile coi pc moderni (d'altronde se devono fare da "desktop" non saranno proprio ciofeche in generale).
Solo che mi dispiace leggere di tante features di KDE (ad es.) e di altrettante persone che consigliano di disattivarle per migliorare "i tempi di risposta" su molti pc ancora in circolazione.
Insomma credo che il mondo Linux non si dovrebbe mai "accontentare", dato che ha come avversario il mondo closed.
Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server
Penso anch'io che sia tutto accettabile coi pc moderni (d'altronde se devono fare da "desktop" non saranno proprio ciofeche in generale).
Solo che mi dispiace leggere di tante features di KDE (ad es.) e di altrettante persone che consigliano di disattivarle per migliorare "i tempi di risposta" su molti pc ancora in circolazione.
Insomma credo che il mondo Linux non si dovrebbe mai "accontentare", dato che ha come avversario il mondo closed.
ilsensine
08-07-2003, 21:14
Originally posted by "Tadde"
Siccome la scelta server-client non è la più efficiente per un uso desktop
...infatti XFree usa tecniche diverse (non client-server) sul computer locale.
Come detto altre volte, una eventuale lentezza non è colpa di XFree, ma dei window manager/toolkit che usi.
Siccome la scelta server-client non è la più efficiente per un uso desktop
...infatti XFree usa tecniche diverse (non client-server) sul computer locale.
Come detto altre volte, una eventuale lentezza non è colpa di XFree, ma dei window manager/toolkit che usi.
Pang
08-07-2003, 21:30
Potresti spiegarci perchè xfree86 non sarebbe adatto ad un uso desktop, sono curioso.
Ciao
Ciao
HollowMan
08-07-2003, 21:42
Originally posted by "ilsensine"
...infatti XFree usa tecniche diverse (non client-server) sul computer locale.
Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?
...infatti XFree usa tecniche diverse (non client-server) sul computer locale.
Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?
jappilas
08-07-2003, 22:11
ma.. in effetti... per quello che ho visto su basi generiche di GUI varie (gdi, X ecc) sembrerebbe che il concetto client server ha un suo senso ...
infatti , se si vuole avere che : le applicazioni non debbano gestire loro direttamente tutto il redraw delle finestre delle icone ecc , e quindi si appoggino a uno "strato" che astragga queste funzioni e le renda disponibili come funzioni ...
un server è la soluzione che se concepita decentemente offre la maggiore generalizzazione e versatilità crea la schermata partendo dal contenuto delle finestre, toolbar ecc , menrte il modulo client che può essere interno od esterno si occupa della visualizzazione e interazione via mouse e tastiera...
ora... 2 processi nel sistema ci dovrebbero essere comunque... l pesantezza non è intrinsica del concetto di server ma dell' implementazione (window manager , driver ecc)
l' alternativa al server quale sarebbe ? una libreria di accesso diretto al' hardware? secondo me in ogni caso bisognerebbe riprogettare del tutto le applicazioni con GUI
e mi pare di notare che nel mondo linux per tante applicaziuoni è già tanto avere delle gui figurati se gli sviluppatori buttano via quello che si sa su X già ampiamente diffuso e colludato da decenni per qualcosa di radicalmente nuovo... una cosa così magari andrebbe per applicazioni specifiche, embedded o giochi ma per cose generiche no
infatti , se si vuole avere che : le applicazioni non debbano gestire loro direttamente tutto il redraw delle finestre delle icone ecc , e quindi si appoggino a uno "strato" che astragga queste funzioni e le renda disponibili come funzioni ...
un server è la soluzione che se concepita decentemente offre la maggiore generalizzazione e versatilità crea la schermata partendo dal contenuto delle finestre, toolbar ecc , menrte il modulo client che può essere interno od esterno si occupa della visualizzazione e interazione via mouse e tastiera...
ora... 2 processi nel sistema ci dovrebbero essere comunque... l pesantezza non è intrinsica del concetto di server ma dell' implementazione (window manager , driver ecc)
l' alternativa al server quale sarebbe ? una libreria di accesso diretto al' hardware? secondo me in ogni caso bisognerebbe riprogettare del tutto le applicazioni con GUI
e mi pare di notare che nel mondo linux per tante applicaziuoni è già tanto avere delle gui figurati se gli sviluppatori buttano via quello che si sa su X già ampiamente diffuso e colludato da decenni per qualcosa di radicalmente nuovo... una cosa così magari andrebbe per applicazioni specifiche, embedded o giochi ma per cose generiche no
Black imp
09-07-2003, 01:20
Originally posted by "HollowMan"
Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?
mi associo alla domanda. puoi darci almeno dei link ?
a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba! :muro:
Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?
mi associo alla domanda. puoi darci almeno dei link ?
a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba! :muro:
AnonimoVeneziano
09-07-2003, 01:34
Mha, non riesco a capire dove vediate il rallentamento, per me è solo un fattore psicologico , per quanto mi riguarda a me scheggia tutto alla perfezione .
Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.
Poi ormai X è uno standard, tutte le librerie sono scritte per X , e i programmi sono scritti per usare quelle librerie, un cambiamento di standard provocherebbe un obbligo di riscrittura di tutte le librerie grafiche , e poi probabilmente anke dei vari programmi che fanno uso delle librerie stesse , un lavoro troppo grande e impensabile .
Ciao
PS= COmunque devo ammettere che sono di parte, perchè X è un componente che mi ha sempre affascinato, e sarebbe una grande perdita sostituirlo , e inoltre la sostituzione con qualcosa di Embedded porterebbe a un integrazione tra interfaccia grafica e kernel , e se l'interfaccia si dovesse inchiodare probabilmente anke il kernel si inchioderebbe . Per non parlare della impossibile varietà che otterremmo. Oggi abbiamo KDE , GNOME , Wmaker, XFCE..... domani avremo interfacce grafiche stand-alone , che comprenderanno tutto, questo provocherà che le librerie scritte per uno non è detto che funzioneranno per l'altra, e il programma X scritto per uno non è detto che funzionerà con l'altro, e inoltre ci vorranno drivers diversi per ogni interfaccia.......
Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.
Poi ormai X è uno standard, tutte le librerie sono scritte per X , e i programmi sono scritti per usare quelle librerie, un cambiamento di standard provocherebbe un obbligo di riscrittura di tutte le librerie grafiche , e poi probabilmente anke dei vari programmi che fanno uso delle librerie stesse , un lavoro troppo grande e impensabile .
Ciao
PS= COmunque devo ammettere che sono di parte, perchè X è un componente che mi ha sempre affascinato, e sarebbe una grande perdita sostituirlo , e inoltre la sostituzione con qualcosa di Embedded porterebbe a un integrazione tra interfaccia grafica e kernel , e se l'interfaccia si dovesse inchiodare probabilmente anke il kernel si inchioderebbe . Per non parlare della impossibile varietà che otterremmo. Oggi abbiamo KDE , GNOME , Wmaker, XFCE..... domani avremo interfacce grafiche stand-alone , che comprenderanno tutto, questo provocherà che le librerie scritte per uno non è detto che funzioneranno per l'altra, e il programma X scritto per uno non è detto che funzionerà con l'altro, e inoltre ci vorranno drivers diversi per ogni interfaccia.......
Ikitt_Claw
09-07-2003, 07:23
Originally posted by "Black imp"
mi associo alla domanda. puoi darci almeno dei link ?
link no, qualche keyword tipo
dri, dga, xv (sull'ultima non sono sicurissimo) si.
XFree86 e` _molto_ meno "lento & brutto" di come lo si dipinge.
[/quote]
a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba! :muro:[/quote]
Hai qualche dato, rilevazione o confronto o si va ad impressioni?
Perche` la mia, di impressione, e` che un kernel preempt+Xfree4 tenga ormai benissimo il confronto con windows, quanto a reattivita` e prestazioni pure.
mi associo alla domanda. puoi darci almeno dei link ?
link no, qualche keyword tipo
dri, dga, xv (sull'ultima non sono sicurissimo) si.
XFree86 e` _molto_ meno "lento & brutto" di come lo si dipinge.
[/quote]
a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba! :muro:[/quote]
Hai qualche dato, rilevazione o confronto o si va ad impressioni?
Perche` la mia, di impressione, e` che un kernel preempt+Xfree4 tenga ormai benissimo il confronto con windows, quanto a reattivita` e prestazioni pure.
ilsensine
09-07-2003, 07:36
Originally posted by "AnonimoVeneziano"
Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.
Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.
La Xv è molto utilizzata per scrivere direttamente sulla memoria video (ad es. i player video usano questa tecnica).
Queste implementazioni sono molto veloci, tanto che uso un "server" X relativamente completo sul mio iPaq aziendale, e con IceWM ottengo ottime prestazioni.
Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.
Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.
La Xv è molto utilizzata per scrivere direttamente sulla memoria video (ad es. i player video usano questa tecnica).
Queste implementazioni sono molto veloci, tanto che uso un "server" X relativamente completo sul mio iPaq aziendale, e con IceWM ottengo ottime prestazioni.
HollowMan
09-07-2003, 09:16
Originally posted by "ilsensine"
Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.
Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è :)
Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...
Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.
Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è :)
Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...
ilsensine
09-07-2003, 09:31
Originally posted by "HollowMan"
Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è :)
Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no? :)
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".
Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...
Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.
Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è :)
Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no? :)
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".
Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...
Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.
HollowMan
09-07-2003, 09:57
Originally posted by "ilsensine"
Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no? :)
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".
Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa .... :)
io sono sempre stato abituato a definire "server" un qualsiasi processo in attesa di comandi da un altro processo definito "client" ... a prescindere dalla locazione dei due processi e dal fatto che la comunicazione avvenga attraverso socket o pipe o memoria condivisa.
Ma questo penso sia dovuto al fatto che per me client-server è un concetto prima che un'implementazione :D
Originally posted by "ilsensine"
Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.
Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.
Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no? :)
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".
Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa .... :)
io sono sempre stato abituato a definire "server" un qualsiasi processo in attesa di comandi da un altro processo definito "client" ... a prescindere dalla locazione dei due processi e dal fatto che la comunicazione avvenga attraverso socket o pipe o memoria condivisa.
Ma questo penso sia dovuto al fatto che per me client-server è un concetto prima che un'implementazione :D
Originally posted by "ilsensine"
Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.
Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.
ilsensine
09-07-2003, 10:01
Originally posted by "HollowMan"
Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa .... :)
Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server ;)
Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.
Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato ;)
Fidati, X+wm funziona egregiamente anche sui palmari ;)
Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa .... :)
Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server ;)
Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.
Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato ;)
Fidati, X+wm funziona egregiamente anche sui palmari ;)
HollowMan
09-07-2003, 10:14
Originally posted by "ilsensine"
Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server ;)
ma Windows non ha il sottosistema grafico integrato nel kernel ?
Originally posted by "ilsensine"
Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato ;)
Fidati, X+wm funziona egregiamente anche sui palmari ;)
Si lo so che funziona egregiamente, dicevo solo che anche le qt non sono male come toolkit, e lo dico da utente gnome :D
Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server ;)
ma Windows non ha il sottosistema grafico integrato nel kernel ?
Originally posted by "ilsensine"
Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato ;)
Fidati, X+wm funziona egregiamente anche sui palmari ;)
Si lo so che funziona egregiamente, dicevo solo che anche le qt non sono male come toolkit, e lo dico da utente gnome :D
ilsensine
09-07-2003, 10:31
Originally posted by "HollowMan"
ma Windows non ha il sottosistema grafico integrato nel kernel ?
...e perché, il kernel non è un "programma"? :p
ma Windows non ha il sottosistema grafico integrato nel kernel ?
...e perché, il kernel non è un "programma"? :p
HollowMan
09-07-2003, 10:46
Originally posted by "ilsensine"
...e perché, il kernel non è un "programma"? :p
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
...e perché, il kernel non è un "programma"? :p
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
ilsensine
09-07-2003, 10:57
Originally posted by "HollowMan"
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
?
XFree a runtime è un singolo processo che ingloba il sottosistema grafico
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
?
XFree a runtime è un singolo processo che ingloba il sottosistema grafico
HollowMan
09-07-2003, 11:16
Si, ma se lo fai partire da solo (intendo l'eseguibile /usr/X11/bin/X che è appunto il server grafico) ti da una bella schermata grigia e un cursore a forma di X ... nient'altro ... se vuoi fagli disegnare qualcosa (da locale o da remoto che sia) devi usare, o meglio eseguire, un client come ad esempio un window manager.
Nel kernel di windows queste due classi di operazioni sono appannaggio dello stesso processo.
Quello che voglio dire è che il sottosistema grafico di windows è un singolo processo tutto incluso nel kernel, mentre il sottosistema grafico di linux è composto da diversi processi e prova ne è che li puoi eseguire separatamente, mentre il kernel di windows è un monoblocco :)
Nel kernel di windows queste due classi di operazioni sono appannaggio dello stesso processo.
Quello che voglio dire è che il sottosistema grafico di windows è un singolo processo tutto incluso nel kernel, mentre il sottosistema grafico di linux è composto da diversi processi e prova ne è che li puoi eseguire separatamente, mentre il kernel di windows è un monoblocco :)
ilsensine
09-07-2003, 11:24
Originally posted by "HollowMan"
Si, ma se lo fai partire da solo (intendo l'eseguibile /usr/X11/bin/X che è appunto il server grafico) ti da una bella schermata grigia e un cursore a forma di X ... nient'altro ... se vuoi fagli disegnare qualcosa (da locale o da remoto che sia) devi usare, o meglio eseguire, un client come ad esempio un window manager.
Nel kernel di windows queste due classi di operazioni sono appannaggio dello stesso processo.
Sicuro "dello stesso processo"? Normalmente un kernel esegue più processi per i vari scopi. E' vero per linux, e credo a maggior ragione vero per Windows, che ha molte cose integrate.
...e poi, fai partire windows senza lanciare explorer.exe, ti ritroverai con un bellissimo sfondo monocolore :D (mai provato a farlo? Io sì :) )
Separare la gestione grafica dal kernel e demandarla a un processo in user space non ha impatto sulle prestazioni. Ha solo vantaggi per la sicurezza. La struttura "client-server" non dipende da dove sia il "server"; ti posso portare ad esempio l'nfs: il codice "server" oggi è all'interno del kernel linux, ma sempre server è :)
Si, ma se lo fai partire da solo (intendo l'eseguibile /usr/X11/bin/X che è appunto il server grafico) ti da una bella schermata grigia e un cursore a forma di X ... nient'altro ... se vuoi fagli disegnare qualcosa (da locale o da remoto che sia) devi usare, o meglio eseguire, un client come ad esempio un window manager.
Nel kernel di windows queste due classi di operazioni sono appannaggio dello stesso processo.
Sicuro "dello stesso processo"? Normalmente un kernel esegue più processi per i vari scopi. E' vero per linux, e credo a maggior ragione vero per Windows, che ha molte cose integrate.
...e poi, fai partire windows senza lanciare explorer.exe, ti ritroverai con un bellissimo sfondo monocolore :D (mai provato a farlo? Io sì :) )
Separare la gestione grafica dal kernel e demandarla a un processo in user space non ha impatto sulle prestazioni. Ha solo vantaggi per la sicurezza. La struttura "client-server" non dipende da dove sia il "server"; ti posso portare ad esempio l'nfs: il codice "server" oggi è all'interno del kernel linux, ma sempre server è :)
AnonimoVeneziano
09-07-2003, 11:44
Originally posted by "HollowMan"
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
E ti sembra un bel sistema di gestire le cose ? Se si impalla il sistema grafico ti si impalla anke Linux . Il 50% dell' instabilità di WIndows è provocata da questo. Se si impalla il server X su linux basta che fai "CTRL +ALT + Backspace" e poi dai startx e hai il tuo X di nuovo funzionante su windows dai il Reset . DIrei che la differenza si vede.
Per quanto ne so l'unico modo per far inchiodare linux tramite l'interfaccia grafica è tramite DRI e DGA che richiedono entrambi accesso diretto al kernel
Ciao
Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...
E ti sembra un bel sistema di gestire le cose ? Se si impalla il sistema grafico ti si impalla anke Linux . Il 50% dell' instabilità di WIndows è provocata da questo. Se si impalla il server X su linux basta che fai "CTRL +ALT + Backspace" e poi dai startx e hai il tuo X di nuovo funzionante su windows dai il Reset . DIrei che la differenza si vede.
Per quanto ne so l'unico modo per far inchiodare linux tramite l'interfaccia grafica è tramite DRI e DGA che richiedono entrambi accesso diretto al kernel
Ciao
HollowMan
09-07-2003, 11:49
Mi accorgo di essere effettivamente indietro sulle implementazioni MS ... dunque in base a quanto emerso dalla discussione si può dire che anche windows ha una struttura client-server, anche se la comunicazione è limitata all'uso di memoria condivisa (presumo).
L'esempio di nfs mi vede concorde, e d'altronde conferma la mia tesi che al di la della metodologia di comunicazione X presenta sempre e comunque una struttura client-server :)
L'esempio di nfs mi vede concorde, e d'altronde conferma la mia tesi che al di la della metodologia di comunicazione X presenta sempre e comunque una struttura client-server :)
HollowMan
09-07-2003, 11:55
Originally posted by "AnonimoVeneziano"
E ti sembra un bel sistema di gestire le cose ?
Mai affermato ... infatti se preferisco Linux un motivo ci sarà :)
Originally posted by "AnonimoVeneziano"
Se si impalla il sistema grafico ti si impalla anke Linux
forse volevi dire Windows ... il kernel di cui parlavo era quello di Windows :)
E ti sembra un bel sistema di gestire le cose ?
Mai affermato ... infatti se preferisco Linux un motivo ci sarà :)
Originally posted by "AnonimoVeneziano"
Se si impalla il sistema grafico ti si impalla anke Linux
forse volevi dire Windows ... il kernel di cui parlavo era quello di Windows :)
ilsensine
09-07-2003, 11:56
Originally posted by "HollowMan"
Mi accorgo di essere effettivamente indietro sulle implementazioni MS ... dunque in base a quanto emerso dalla discussione si può dire che anche windows ha una struttura client-server, anche se la comunicazione è limitata all'uso di memoria condivisa (presumo).
L'esempio di nfs mi vede concorde, e d'altronde conferma la mia tesi che al di la della metodologia di comunicazione X presenta sempre e comunque una struttura client-server :)
Forse dovresti "ammorbidire" la tua visione di sistema "client-server", è troppo rigida ;)
Così come la intendi, implica che qualsiasi chiamata fatta al sistema operativo, a qualsiasi scopo, è una richiesta da una applicazione "client" ad una "server". Benché questo sia a rigor di logica corretto, normalmente si intende come struttura "client/server" una struttura che per funzionare non pone particolari vincoli sulla locazione fisica dei due processi. Il server xfree può farlo, Windows terminal server anche, ma non per questo non possono gestire efficacemente processi "locali", tramite protocolli più diretti.
Mi accorgo di essere effettivamente indietro sulle implementazioni MS ... dunque in base a quanto emerso dalla discussione si può dire che anche windows ha una struttura client-server, anche se la comunicazione è limitata all'uso di memoria condivisa (presumo).
L'esempio di nfs mi vede concorde, e d'altronde conferma la mia tesi che al di la della metodologia di comunicazione X presenta sempre e comunque una struttura client-server :)
Forse dovresti "ammorbidire" la tua visione di sistema "client-server", è troppo rigida ;)
Così come la intendi, implica che qualsiasi chiamata fatta al sistema operativo, a qualsiasi scopo, è una richiesta da una applicazione "client" ad una "server". Benché questo sia a rigor di logica corretto, normalmente si intende come struttura "client/server" una struttura che per funzionare non pone particolari vincoli sulla locazione fisica dei due processi. Il server xfree può farlo, Windows terminal server anche, ma non per questo non possono gestire efficacemente processi "locali", tramite protocolli più diretti.
Black imp
09-07-2003, 11:58
insomma in sostanza mi pare di capire che come volevasi dimostrare sotto c'è sempre una struttura client server - nell'unica accezione che ha questo termine - e che mentre winzoz gestisce la grafica con un processo a livello kernel , linux la gestisce sì con un processo ma a livello utente e se è così si capisce che è per forza più lento. Ho capito bene?
ilsensine
09-07-2003, 12:00
Originally posted by "Black imp"
e che mentre winzoz gestisce la grafica con un processo a livello kernel , linux la gestisce sì con un processo ma a livello utente e se è così si capisce che è per forza più lento. Ho capito bene?
Per quale masochistico motivo un processo in kernel space sarebbe più veloce di un processo in user space? Risulta più simpatico al processore? :sofico:
e che mentre winzoz gestisce la grafica con un processo a livello kernel , linux la gestisce sì con un processo ma a livello utente e se è così si capisce che è per forza più lento. Ho capito bene?
Per quale masochistico motivo un processo in kernel space sarebbe più veloce di un processo in user space? Risulta più simpatico al processore? :sofico:
Tadde
09-07-2003, 12:00
Insomma ritornando IT e cercando di essere IL PIU' OBIETTIVI POSSIBILE, voi mi state dicendo che a parità di HW un WinXP non è più "veloce" e "pronto" di un KDE con le sue impostazioni di default? E con tutti i gingilli al massimo?
HollowMan
09-07-2003, 12:00
Originally posted by "ilsensine"
.... normalmente si intende come struttura "client/server" una struttura che per funzionare non pone particolari vincoli sulla locazione fisica dei due processi.
Aspetta, ma questo è proprio quello che voglio dire anch'io, infatti per questo ritengo che X sia client-server, mentre il sottosistema grafico di Windows non lo sia.
Forse quello che ha causato il fraintendimento è l'aver detto che anche in locale, usando la shared memory, io considero ancora client-server la struttura di X.
.... normalmente si intende come struttura "client/server" una struttura che per funzionare non pone particolari vincoli sulla locazione fisica dei due processi.
Aspetta, ma questo è proprio quello che voglio dire anch'io, infatti per questo ritengo che X sia client-server, mentre il sottosistema grafico di Windows non lo sia.
Forse quello che ha causato il fraintendimento è l'aver detto che anche in locale, usando la shared memory, io considero ancora client-server la struttura di X.
ilsensine
09-07-2003, 12:01
Originally posted by "Tadde"
Insomma ritornando IT e cercando di essere IL PIU' OBIETTIVI POSSIBILE, voi mi state dicendo che a parità di HW un WinXP non è più "veloce" e "pronto" di un KDE con le sue impostazioni di default? E con tutti i gingilli al massimo?
KDE (e _non_ XFree) è un bel bisonte.
Sotto Linux esistono una marea di window manager, dal più veloce al più "accattivante".
Se ritieni KDE lento, bè...puoi cambiarlo con qualcos'altro
Se ritieni WinXP lento, bè...te lo tieni :D
Insomma ritornando IT e cercando di essere IL PIU' OBIETTIVI POSSIBILE, voi mi state dicendo che a parità di HW un WinXP non è più "veloce" e "pronto" di un KDE con le sue impostazioni di default? E con tutti i gingilli al massimo?
KDE (e _non_ XFree) è un bel bisonte.
Sotto Linux esistono una marea di window manager, dal più veloce al più "accattivante".
Se ritieni KDE lento, bè...puoi cambiarlo con qualcos'altro
Se ritieni WinXP lento, bè...te lo tieni :D
ilsensine
09-07-2003, 12:04
Originally posted by "HollowMan"
Aspetta, ma questo è proprio quello che voglio dire anch'io, infatti per questo ritengo che X sia client-server, mentre il sottosistema grafico di Windows non lo sia.
Forse quello che ha causato il fraintendimento è l'aver detto che anche in locale, usando la shared memory, io considero ancora client-server la struttura di X.
Guarda il mio esempio sul Terminal Server. Usa una trasmissione via socket per i client remoti, e una struttura diretta per i client "locali". Appunto quello che fa XFree.
Aspetta, ma questo è proprio quello che voglio dire anch'io, infatti per questo ritengo che X sia client-server, mentre il sottosistema grafico di Windows non lo sia.
Forse quello che ha causato il fraintendimento è l'aver detto che anche in locale, usando la shared memory, io considero ancora client-server la struttura di X.
Guarda il mio esempio sul Terminal Server. Usa una trasmissione via socket per i client remoti, e una struttura diretta per i client "locali". Appunto quello che fa XFree.
Tadde
09-07-2003, 12:05
Originally posted by "ilsensine"
Assolutamente no, in quanto KDE (e _non_ XFree) è un bel bisonte.
Sotto Linux esistono una marea di window manager, dal più veloce al più "accattivante".
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Assolutamente no, in quanto KDE (e _non_ XFree) è un bel bisonte.
Sotto Linux esistono una marea di window manager, dal più veloce al più "accattivante".
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Black imp
09-07-2003, 12:11
Originally posted by "ilsensine"
Per quale masochistico motivo un processo in kernel space sarebbe più veloce di un processo in user space? Risulta più simpatico al processore? :sofico:
??? a me, ingenuamente forse, sembrava palese :rolleyes:
Per quale masochistico motivo un processo in kernel space sarebbe più veloce di un processo in user space? Risulta più simpatico al processore? :sofico:
??? a me, ingenuamente forse, sembrava palese :rolleyes:
ilsensine
09-07-2003, 12:12
Originally posted by "Tadde"
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Per un computer sufficientemente potente (aka: non un ferrovecchio), non ci sono differenze di rilievo, per quel che riguarda il window manager. Puoi trovare differenze con programmi specifici, ad es. Mozilla è un pò più lento di iexplorer (almeno per quel che ho potuto verificare).
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Per un computer sufficientemente potente (aka: non un ferrovecchio), non ci sono differenze di rilievo, per quel che riguarda il window manager. Puoi trovare differenze con programmi specifici, ad es. Mozilla è un pò più lento di iexplorer (almeno per quel che ho potuto verificare).
ilsensine
09-07-2003, 12:14
Originally posted by "Black imp"
??? a me, ingenuamente forse, sembrava palese :rolleyes:
L'unica differenza è che le pagine di memoria di un processo utente possono essere soggette a swap (un processo root può evitarlo, se ritiene opportuno - credo che XFree lo faccia in alcuni punti). A parte questo, la velocità è identica, a parità di priorità (la gestione della priorità per i kernel thread è uguale a quella dei processi utente).
??? a me, ingenuamente forse, sembrava palese :rolleyes:
L'unica differenza è che le pagine di memoria di un processo utente possono essere soggette a swap (un processo root può evitarlo, se ritiene opportuno - credo che XFree lo faccia in alcuni punti). A parte questo, la velocità è identica, a parità di priorità (la gestione della priorità per i kernel thread è uguale a quella dei processi utente).
HollowMan
09-07-2003, 12:14
Originally posted by "Tadde"
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Beh, XP di default di fronzoli non ne ha molti. E se cominci ad usare qualche programmino che ti modifica lo stile delle finestre, il grado di trasparenza, e cose di questo tipo (mi viene in mente StyleXP che è quello che uso io) vedi che anche Windows presenta i suoi bei rallentamenti.
I compromessi vanno fatti su entrambi si sistemi operativi, con la non trascurabile particolarità che sotto Linux almeno ti puoi scegliere il windows manager più adatto alle risorse della macchina: io sul portatile ho in programma di passare da gnome a xfce4 per dargli un pò + di respiro ( è un P3 a 600Mhz) mentre sul desktop (Athlon 1800) abbondo con i fronzoli di gnome :D
Bene, ho scritto di kde perché è quello che mi sembra dotato di maggior "eye-candy" .
Il senso della mia domanda è quanto si debba scendere a compromessi con i fronzoli (animazioni/trasparenze delle finestre ecc...) di un sistema grafico installato su Linux per poter percepire la stessa "velocità di risposta" che mi sembra di percepire su un winxp (al quale però mi sono abituato, questo va tenuto in conto).
Beh, XP di default di fronzoli non ne ha molti. E se cominci ad usare qualche programmino che ti modifica lo stile delle finestre, il grado di trasparenza, e cose di questo tipo (mi viene in mente StyleXP che è quello che uso io) vedi che anche Windows presenta i suoi bei rallentamenti.
I compromessi vanno fatti su entrambi si sistemi operativi, con la non trascurabile particolarità che sotto Linux almeno ti puoi scegliere il windows manager più adatto alle risorse della macchina: io sul portatile ho in programma di passare da gnome a xfce4 per dargli un pò + di respiro ( è un P3 a 600Mhz) mentre sul desktop (Athlon 1800) abbondo con i fronzoli di gnome :D
Black imp
09-07-2003, 12:29
Originally posted by "ilsensine"
L'unica differenza è che le pagine di memoria di un processo utente possono essere soggette a swap (un processo root può evitarlo, se ritiene opportuno - credo che XFree lo faccia in alcuni punti). A parte questo, la velocità è identica, a parità di priorità (la gestione della priorità per i kernel thread è uguale a quella dei processi utente).
scusa ma non hanno priorità più alta i processi kernel? a parte che dipende dall'architettura ma rimaniamo su linux.
L'unica differenza è che le pagine di memoria di un processo utente possono essere soggette a swap (un processo root può evitarlo, se ritiene opportuno - credo che XFree lo faccia in alcuni punti). A parte questo, la velocità è identica, a parità di priorità (la gestione della priorità per i kernel thread è uguale a quella dei processi utente).
scusa ma non hanno priorità più alta i processi kernel? a parte che dipende dall'architettura ma rimaniamo su linux.
ilsensine
09-07-2003, 12:35
Originally posted by "Black imp"
scusa ma non hanno priorità più alta i processi kernel? a parte che dipende dall'architettura ma rimaniamo su linux.
E per quale motivo dovrebbero averla?
Alcuni criciali (come mdrecoveryd) hanno nice massimo (-20); altri (ksoftirqd) hanno priorità quasi idle (19), ma molti sono "0", come quasi tutti i processi utente.
Per la cronaca, sul mio sistema XFree gira con nice -10, quindi con priorità molto più elevata della maggior parte dei kernel thread.
scusa ma non hanno priorità più alta i processi kernel? a parte che dipende dall'architettura ma rimaniamo su linux.
E per quale motivo dovrebbero averla?
Alcuni criciali (come mdrecoveryd) hanno nice massimo (-20); altri (ksoftirqd) hanno priorità quasi idle (19), ma molti sono "0", come quasi tutti i processi utente.
Per la cronaca, sul mio sistema XFree gira con nice -10, quindi con priorità molto più elevata della maggior parte dei kernel thread.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.