Newsgroup: it.comp.os.dibattiti
Titolo: x-window

Vorrei porre una questione sull'architettura di x-window.
Questa utilizza lo stack tcp/ip per l'I/O.
Cio' non dovrebbe rallentarne le prestazioni? Soprattutto con le nuove 
GUI come Gnome che lo utilizzano in maniera massiccia?
Tra l'altro mi sembra che lo stack tcp/ip in questo caso sia utilizzato 
in maniera "impropria"...
Allora, se l'utilizzo "improprio" dello stack desse vantaggi 
prestazionali, potrei capire...
Ma visto che da solo svantaggi, non sarebbe meglio utilizzare altre 
architetture?
Tipo, chenneso', un terminale che supporta, oltre alla modalita' 
testuale e alla modalita' svga (con la svgalib), la libreria xlib. In 
questo modo i processi eseguiti dall'ambiente grafico comunicherebbero 
direttamente col terminale, senza passare dallo stack tcp/ip...
Voi cosa ne pensate?

 Questa utilizza lo stack tcp/ip per l'I/O.
no
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 in maniera "impropria"...
No. In rete d'accordo, ma in locale usa ipc (inter process communication,
unix domain sockets)
bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 Voi cosa ne pensate?
Che devi chiarire meglio il concetto che vuoi esprimere.
Cosa intendi per: I/O?
bye,
-- 
   Piergiorgio Sartor

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true. [J. Robert Oppenheimer]

 architetture?
Infatti, già succede.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)       [ 
http://digilander.libero.it/ebassi/blog
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 una fava.
Non vorrei dire fesserie, ma i socket sono un layer comune per le
comunicazioni in generale, estensione di unix gia' in principio studiata in
modo da essere la piu' vasta e versatile possibile (in breve, aprire un socket
per una connessione in rete non prevede solo il caso particolare del tcp/ip
che mi sembra si chiami AF_INET).
Senza con cio' togliere che un unix domain socket e' ovviamente sempre mooolto
piu' veloce e immediato che non un socket di connessione di rete.    :-)


Scusate, erano anche le 2.
Di solito io i socket li uso per fare connessioni tcp/ip, quindi ho 
fatto nel mio subconscio un minestrone mentale ed e' venuta fuori quella 
roba li'.
Riformulando la domanda: usare gli unix sockets per l'Input/Output tra 
X-Server e clients non porta a creare un'architettura "ingombrante" e 
(altro quesito che ieri sera mi son dimenticato di inserire) scomoda se 
si vogliono implementare cose tipo il drag'n'drop e una gui stile 
kde/gnome (che in effetti sono + lenti di un window manager liscio)?


E' confortante sapere che qualcun'altro ha pensato a 'sta cosa, adesso 
mi sento meno svitato.


[cut]
   A questo punto gradirei una spiegazione sulla differenza tra XDirectFB 
(a parte il fatto che utilizza DirectFB per il rendering) e il "classico" 
XFree86 per il framebuffer: sono o non sono entrambi dei server X ??? 
Quindi con tanto di comunicazione sulla ormai "famigerata" unix socket ??? 
Oppure XDirectFB offre una xlib "alternativa" che si interfaccia 
direttamente al DirectFB ??? In tal caso sarebbe una cosa interessante, 
altrimenti ci vedrei poco di innovativo...
   E, finalmente si risolverebbe  l'annoso (IMHO) dilemma sul fatto del 
perche` la scheda video debba essere trattata in maniera differente dal 
resto dell'hardware, in linux, visto e considerato che, almeno fino al 
supporto per fb e dri, la scheda video era l'unico pezzo del computer in 
cui l'interfaccia non avveniva tramite il kernel ma tramite un programma 
tutto in user space. Non che questo sia un male, de gustibus, sia ben 
chiaro, pero` rende "asimmetrico" il trattamento della scheda video...
   OK, non seppellitemi se ho detto un mare di cazzate, del resto e` 
l'alba!!! ;-)
Vh
-- 
                          | Mi sto arrabbiando...
\|/ ____ \|/   \ ||_|     | ...non vi piacerebbe vedermi
"@'/ ,. \`@"    \|| |     |    arrabbiato...
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |       Dr. David Bruce Banner

 default un utente normale non puo' masterizzare).
   Beh, qui stiamo parlando di qualcosa di un po' diverso: facciamo un 
parallelo con la scheda audio, ad esempio... Il kernel, in quel caso, offre 
ai programmi in user space (tramite gli appositi device) delle api per fare 
I/O sulla periferica in questione. Nel caso della scheda video (senza 
parlare di fb e DRI, perche`, tanto, li potremmo tranquillamente non 
compilare nel kernel e i server X se ne sbatterebbero allegramente) invece, 
il kernel non sa nemmeno che c'e` una scheda video (o quasi): il server X, 
in questo caso, si interfaccia direttamente con l'hw (a proposito, ma come 
accidenti fa ??) e fornisce lui le api agli applicativi: e` come se ci 
fossero "due" kernel, uno che si occupa di tutto l'hw, l'altro, in user 
space, dedicato alla sola scheda video (azz, i sistemi con X sono a 
microkernel e non lo sapevamo ;-), ok era una battuta)... E` questo, IMHO, 
che mi da` l'idea di una vaga asimmetria di quest'ultima rispetto al resto 
dell'hw...
   Non sto parlando di comodita`, scomodita`, o altro, anzi, probabilmente, 
dal punto di vista di chi scrive il kernel, "dimenticarsi" della scheda 
video non e` nemmeno un male...
Vh
-- 
                          | Almeno tu che puoi fuggi via canto
\|/ ____ \|/   \ ||_|     | nomade questa cella e` piena della
"@'/ ,. \`@"    \|| |     | mia disperazione tu che puoi non
/_| \__/ |_\ Vax Headroom | farti prendere.
   \__U_/                 |                    BMS

Bimbo Vispo wrote:

Anche windows usa un meccanismo di comunicazione inter-process tra
l'applicazione a la GUI (hint: NT era predisposto per i terminal services, o
meglio per l'antesignano citrix).
I motivi della minore velocita' sono altri, e se ne e' lungamente discusso
su ICOD. Il fatto che la GUI gira a ring 3 (user mode), il maggiore overhead
del protocollo X, i drivers della scheda grafica non sempre ottimizzati e/o
deficitari di qualche determinato supporto. Comunque, in un confronto fra
win2k e X sulla medesima macchina, con la stessa applicazione grafica
intensiva portata nei due ambienti, e con drivers e supporto ottimizzati per
entrambe gli ambienti, X ha mostrato che dava mediamente l'80-85% delle
performance di NT. Direi che, visti i presunti svantaggi "strutturali"
rispetto a NT (l'anzianita' del protocollo X, ed il fatto che gira a ring
3), potrei desumere che in realta' X, a conti fatti, batte NT...



Correggetemi se dico fesserie: Xfree versione 3, ha dei server specializzati
ognuno per un gruppo di schede, ed il driver e' "hardcoded" nell'eseguibile X.
Per cio' che riguarda Xfree versione 4, ho visto che usa dei moduli appropriati
per le schede video (e non solo per le schede video), tanto che li possiamo IMHO
definire veri e propri drivers. A questo punto non saprei neanche se Xfree 4
"spaciuga" su /dev/mem come il predecessore. Anche se c'e' da considerare un
discorso relativo a shared memory e DGA per accelerare la grafica e bypassare in
parte la comunicazione ipc, in cui anche l'applicativo client deve essere
suidato, per poter accedere direttamente alla ram e alla memoria video  :-)


 accidenti fa ??) 
Se  il driver  non e`  accelerato X  mappa parte  della memoria  grafica
(usando  /dev/mem)  e la  usa  per  disegnarci  sopra. Se il  driver  e`
accelerato  non c'e`  bisogno  di  mappare nulla,  basta  giocare con  i
registri della scheda (sempre /dev/mem).
Luca
-- 
Home: 
http://kronoz.cjb.net
Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus)

 kde/gnome (che in effetti sono + lenti di un window manager liscio)?
Non c'entra nulla l'utilizzo delle unix domain socket con la pesantezza
di GNOME/KDE: quella è inerente al fatto che un desktop environment sarà
più pesante di un semplice window manager, per il fatto che il primo
deve gestire più cose del secondo.
+++
Ad ogni modo, se vuoi qualche informazione in più, fai un giro su:
 
http://www.freedesktop.org


 consigliato che sia usato) da utenti normali, e non uid 0,
il server X, per quello che fa, è sicuramente setuid root


 potrei desumere che in realta' X, a conti fatti, batte NT...
a questo punto aggiungerei: e chi se ne frega? (anche se, ovviamente, è 
tutto falso. Ma questo è trascurabile)


 anche se spegni il compiuter!!!!" (TM), e siamo a posto
http://www.mandrakelinux.com/en/errata.php3#badlg
-- 
gabriele dot giambonini at rcfmedia dot biz

 
http://www.mandrakelinux.com/en/errata.php3#badlg
  Oddio !!! E com'e` possibile ??? Danneggiare un CD-ROM via software ???



Date:
Sunday 26 October 2003 06:24:45
Groups:
alt.os.linux.mandrake
no references
Here's what happened:
LG has redefined a flush command that takes place to decide whether the
drive is a CD-RW. LG has redefined the flush command to mean
"upload firmware" (with predictable results). 
To quote Juan Quintela from the Cooker list, "Yep, who ever decided at LG
that reusing for UPLOAD_FIRMWARE command FLUSH_CACHE command should be
shoot. Twice."
That this behavior has come to the fore as a result of enabling CD-RW packet
writing does not mean that LG is free of fault. This is a hardware issue
and even if Mandrake provides a workaround, this is less than an ideal fix. 
The right thing to do is for LG to release new firmware and contact all of
its customers and tell them how to upgrade it.
So go complain to LG because this is serious. Unfortunately, I huge amount
of damage has been done to Mandrake. In the eyes of many new users, this
will come to be associated with Mandrake.
Hopefully, Mandrake will manage to recover from this issue. I find it
particularly sad because Mandrake 9.2 is very good for the most part.
---------------------------------------------------------------------------
saluti sputtanati

 shoot. Twice."
   D'OH !!!! 8^O
E pensare che ha casa ho un DVD-ROM dell'LG !!! Incrocio i diti !!! E spero 
anche che tutti quegli strani problemi che ho con il modulo ide-scsi siano 
divuti ad altro !!!
-- 
                          |   L'ultima volta che ho fatto
\|/ ____ \|/   \ ||_|     |   sesso ???
"@'/ ,. \`@"    \|| |     |   Era notte, era buio,
/_| \__/ |_\ Vax Headroom |   ero solo...
   \__U_/                 |                 Daniele Luttazzi

 il server X, per quello che fa, č sicuramente setuid root
Lo č. Per forza di cose.


 tutto falso. Ma questo è trascurabile)
Non proprio. Ha una infrastruttura più pesante di NT o no? Se si, allora 
è scritto molto bene, meglio di NT.


 è scritto molto bene, meglio di NT.
Ahimè no, X è certamente scritto bene; ma a 1600x1200 in truecolor (32) XP
vola rispetto a X a 1600x1200 2^16 colori.
Ovviamente parlo di X con DRI e tutto.
Mia modesta opinione: che X in user mode sia più sicuro che dentro il kernel
è cosa ovvia; basterebbe considerare che in un server non ha senso mettere
X.
saluti oggettivi

 X.
Ovvietà di certo, ma non per tutti. :)


 NT... 
Magari! :-)
saluti ludici

 saluti ludici
Guarda che io ci gioco egregiamente! :) Ho giocato con la loki (tutti) e 
nwn. Nessun problema (anzi).


 nwn. Nessun problema (anzi).
Per carità, lo so. Ma giocheresti meglio con un X nel kernel.
saluti egregi

 saluti oggettivi
saluti pignoli
Marcello
-- 
"Linux is built to be used, Windows is built to be sold" (seen in COLAdv)
Visit 
http://www.geocities.com/match_97
marcello (dot) romani (at) libero (dot) it

 "modulo X", si potrebbe evitare di caricarlo).
Se rileggi quel che hai quotato vedrai che dicevo la stessa cosa; non ha
senso avere X in un server, e in un desktop sarebbe meglio che fosse veloce
al massimo.
turbosaluti


Questa e' una discussione che mi ha sempre interessato.
In generale, avere una caratteristica (come X-server) nel kernel... che
svantaggi comporta in se'?
Non intendo cose del tipo "eh, se si pianta...". Anche perche', diciamocelo,
come mai dovrebbe piantarsi?
Leggendo le argomentazioni sembrerebbe di capire qualcosa del tipo "gia' non
si e' sicuri di scrivere qualcosa di stabile in user mode, per cui guai ad
infilarcelo nel kernel". C'e' qualche motivazione piu' solida? Strutturale?
O ho capito male io?
Anche perche' io non ho mai visto crashare la gui di windows. Sempre che sia
quella cio' che e' stato infilato nel kernel. Intendo il simpatico sfondo
con il task manager unica fonte di salvezza quando killate explorer...
Saluti.

 tutto falso. Ma questo è trascurabile)
E chi se ne frega se lei se ne frega? Se se ne frega, puo' stare anche
zitta. Altrimenti argomenti, signorina, argomenti. Ce ne facciamo poco di
queste uscite...    ;-)


 killate explorer...
Perchč i drivers delle schede grafiche ormai sono stabili! Avresti dovuto
vedere nel 95-96, ai tempi di NT4 sp2, quando anche i drivers Matrox erano
"de paura". :-)
saluti terrorizzati

 Per carità, lo so. Ma giocheresti meglio con un X nel kernel.
A dir la verita' non si notano differenze di alcun tipo, benchmarkando
pero' le prestazioni sotto Unix sono state superiori (forum di NWN,
qualche decina di fps).
Il punto e' che X ha molti pregi e molti difetti, e tra i suoi pregi ha
anche la possibilita' di saltare a pie' pari diversi difetti :)
Piuttosto che la velocita' si dovrebbe parlare del protocollo del WM che
non ha piu' ragione di esistere e del fatto che ad ogni estensione che
si implementa si spacca qualche altra estensione.
	nicholas

 qualche decina di fps).
Ad occhio mio e di altri, su linux gira allo stesso modo di windows. Non 
ho provato mac.


 malaccio)....
Il modello di punta ha una scheda da 128 mega :)
Saluti.

 saluti terrorizzati
Saluti con camomilla.

 Cosi' ? A muzzo? Se gli gira? Se c'e' la luna piena di mercoledi'?
La perfezione non e' di questo mondo e un "puntatore vagante" nel kernel
di danni ne fa molti di piu' che un programma utente.
Se non c'e' un motivo piu' che valido (e le prestazioni non lo sono
quasi mai) il software non dovrebbe essere "aggiunto" al kernel, ma
dovrebbe usare il "kernel".
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 modelli intermedi hanno schede in linea.
Non e' colpa mia se il G5 non puo' montare schede da 256.
Comunque eri tu che parlavi di modelli di punta.
Saluti.

 dovrebbe usare il "kernel".
Questo finche' tutto il NUOVO software non inizia ad usare QUEL software...
Saluti.

 spesso basta flasharle...
Eh? Flashare cosa?
Saluti.

 ... In maniera definitiva.
Poi leggo questa affermazione e ne ho la certezza :-)



E con questo ti installi anche una 256 mega?
Saluti.

 dovrebbe usare il "kernel".
Non per rovinare il bel discorso, ma ci terrei a ricordare kHTTPd...
Henryx
-- 
Valentina: "Mi piace inventare gli spettacoli che voglio... quelli
che non riesco a vedere, cerco di sognarli..."
                                          Guido Crepax (1933-2003)

 Non per rovinare il bel discorso, ma ci terrei a ricordare kHTTPd...
Vero.
Pero', senza avere nulla in mano, direi che una GUI e' piu' complessa di
un webserver che serve solo e unicamente pagine statiche.
BTW, io terrei tutto fuori, saro' scemo ...
	nicholas

 Non per rovinare il bel discorso, ma ci terrei a ricordare kHTTPd...
Non e' stato rimosso dal tree ufficiale, infatti?
-- 
 Francesco Romani - Ikitt  | Describe your vision, the meaning is missing |
*** mailserver: 
freemail.it
| Won't anybody listen?                        |
   >>> La questione brevetti software: 
http://www.softwarelibero.org
 <<<



Ma perche' tutti continuano a credere che per fare una cosa veloce bisogna
metterla nel kernel?
Infilare la roba nel kernel e' solo un trucco per fare presto

 
Mettiamo pure tutto nel kernel, cosi' alla fine abbiamo
1) un sistema operativo monotasking
2) oppure implementiamo il multitasking nel kernel, quindi abbiamo un
intero sistema operativo dentro al kernel e quindi niente piu' memoria
protetta (W l'Amiga!)

 Non e' stato rimosso dal tree ufficiale, infatti?
Sul 2.4.22 c'e` ancora. Sul 2.6.0-test9 non saprei (ma lo sapro` :) )


 metterla nel kernel?
Anche tu stai pensando a BeOS e a Photon?


 
Si specialmente a Photon. ma anche a KGI/GGI etc.

 Infilare la roba nel kernel e' solo un trucco per fare presto
Standing ovation, direi.
	nicholas