Newsgroup: it.comp.os.dibattiti
Titolo: Linux GUI nel kernel

Qualcuno ha mai pensato di integrare la grafica nel kernel di linux...
Un po come fa beos o altri sistemi....(Naturalmente non togliendo la 
modalità testo)
Non parlo di un server come X siamo intesi.

 modalità testo)
Beh citiamo anche un so piu' diffuso?
Saluti.

 space sia piu' pericoloso di una bomba atomica.
Di più di più!
Saluti.
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |
\_______Like the Phoenix I rise from the ashes of life________/

 space sia piu' pericoloso di una bomba atomica.
Ti sei dimenticato di dire che provoca il cancro e la sterilità.


 Non parlo di un server come X siamo intesi.
Si, ovvio.
Ciao,
	Nicholas

Risitano Nicolò wrote:
Non capisco perchè c'è una cosi cattiva opinione da parte delle "gente"
verso le interfacce grafiche integrate nel kernel...
Per me la stabbilità non dipende dall'interfaccia ma dal kernel stesso
mal sviluppato (cosa che non si può dire di Linux) ci sono vari progetti di 
sistema operativo che hanno avuto ottimi esiti....
Io avevo pensato ad una cosa come mettere le chiamate ad X a livello delle 
syscall del kernel creando un livello di astrazione per le schede grafiche 
verso l'utente attraverso queste chiamate e verso l'hardware con un driver 
specifico.
Come lo vedete (critiche costruttive "grazie") 

 specifico.
Nel kernel di Linux c'e` gia` il framebuffer con supporto per una decina
di schede grafiche, e unprogetto (
www.directfb.org
) che implementa una
interfaccia grafica in user space sfruttando l'accelerazione offerta dal
framebuffer. Ci stanno portando anche le gtk, e ci gira gia` gimp.
E` molto piu` veloce di X (mplayer usa gia` questa interfaccia e su
macchine non potentissime la differenza si vede a occhio nudo).


Non so Beos, ma non penso che Windows abbia la GUI nel kernel.
E' solo... "di sistema".
Alessandro.

 l'hardware con un driver specifico.
Questo nei kernel recenti lo si sta facendo con il supporto del framebuffer.
Non penso che sia ragionevole supportare niente di piu' dello stretto
necessario a livello di kernel (tipo window manager, gestione dei font...)
perche' se possibile e' meglio gestire le cose complesse al di fuori.
Alessandro
...che quando ha letto del web server integrato nel kernel si e' messo le
mani nei capelli...

 Ti sei dimenticato di dire che provoca il cancro e la sterilità.
Perche` non mettiamo anche Quake  nel kernel? Aggiungere il supporto per
una GUI nel kernel vuol dire praticamente raddoppiare il numero di linee
di codice da mantenere. Senza contare che  a quel punto un bug nella GUI
puo` tirare giu` tutto il sistema. La GUI sta bene li` dov'e` adesso, in
user space.
Ok, X  e` sovradimensionato per un  utente casalingo (tempo fa  c'era un
progetto alternativo, in pratica X  senza la parte server, piu` leggero)
ma la soluzione non metterlo nel kernel...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.

 E' solo... "di sistema".
Nel NT3.51 la GUI girava in userspace, da li` in poi gira in kernel
mode.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Windows /win'dohz/ n. : thirty-two  bit extension and graphical shell to
a sixteen  bit patch to an  eight bit operating system  originally coded
for a  four bit microprocessor  which was  written by a  two-bit company
that can't stand a bit of competition.

 ma la soluzione non metterlo nel kernel...
Sarei felice di vedere questo progetto alternativo, ma il proposito del mio
messaggio era più ampio... non di critica a linux, ma a una credenza diffusa
e IMHO sbagliata.


Risitano Nicolò wrote:
Dopo aver letto un po di risposte sono giunto alla conclusione che non è per 
un fatto di difficoltà che non si fa questa cosa che migliorerebbe 
l'usabilità del sistema e l'apprendimente da parte di utenti "un pò alle 
prime armi" ma per una questione di ideologia.
Linux Testo Windows Grafico non sembra pure a voi ?

 Linux Testo Windows Grafico non sembra pure a voi ?
In effetti sto postando da una consolle tutta nera..
-- 
il *Vide* - ICQ #5301833
Linux user #224141 on Linux machine #106981
http://www.heavy-metal.it
Tessera #8 "Tira Clarenzo e m' illumino d' immenzo"

 su macchine non potentissime la differenza si vede a occhio nudo).
Mplayer deve *necessariamente* farlo. Per poter disegnare l'interfaccia 
sopra ad un filmato con quasi zero uso di CPU, ad esempio. Mplayer è un 
più un programma da videoregistratore che da PC
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 messo le mani nei capelli...
suppongo tu non abbia ancora visto nessun file system remoto su FTP


 Non so Beos, ma non penso che Windows abbia la GUI nel kernel.
solo le code di messaggi, la gestione degli oggetti grafici, e non sono 
sicura di che altro. Credo sia più o meno lo stesso ruolo dell'X-server


 mode.
Kronos, dimmi qual č, in Windows, il ruolo di win32k.sys


 La GUI sta bene li` dov'e` adesso, in user space.
dimmi da che parti è composta la GUI, gienio (<- intenzionale)


 wrote in
news:2jhW9.19506$
YG2.5...@twister1.libero.it
: 

L'unica ragione plausibile è la seguente:
_è_ _troppo_ _tardi_.
 


Io la vedrei come una scelta anche se in fin dei conti e' la stessa cosa.
Alessandro.

 suppongo tu non abbia ancora visto nessun file system remoto su FTP
Quello l'ho visto dopo...
Alessandro.

 Kronos, dimmi qual è, in Windows, il ruolo di win32k.sys
tu poi ci racconti in che modalita gira win32k.sys ? ti do un'indizio :
non e' in modalita utente.
vai anche a farti un giro per le 639 syscall che implementa e poi ne
riparliamo ...
-- 
          "chown linux:users /world"
"E se i filosofi a cena mangiassero colle mani ?"

 L'unico vero problema che mi viene in mente è che ormai è troppo tardi
no,l'unico vero problema e' che implementare una gui (o parte di una) in
kernel space e'_pericoloso_ ,in kernel mode  e' pericoloso programmare
e basta un bug per piantare tutto il sistema,su un sistema operativo che
non fa della gui un punto fondamentale l'unico posto dove puo girare e' un
user space.Non e' troppo tardi,sarebbe solo tremendamente stupido.


 
Perchè stupido basterebbe la buona intenzione è una "marea" di beta tester e 
di sviluppatori intenzionati a farlo...(Cosa che nel mondo GNU\Linux non 
mancano mai)

 ne riparliamo ...
le ho davanti. Non avrei scritto quel post senza prima aver letto tutte 
le NtUser, una per una, assicurandomi di sapere cosa stessi dicendo. Ho 
l'indubbio vantaggio di essere una psicopatica


 Non e' troppo tardi,sarebbe solo tremendamente stupido.
(imita anche il mio stile! sono commossa)


 Sarei felice di vedere questo progetto alternativo
Si chiamava Berlin, ma adesso ha cambiato nome...
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)              [ 
http://digilander.iol.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 (imita anche il mio stile! sono commossa)
fai che sia _molto_ bravo quello da cui ti farai vedere eh ..


 mancano mai)
IMHO,non sono le risorse a mancare ma le motivazioni,a parte lo
stravolgimento che questo porterebbe ,non mi vengono in mente motivazioni
valide per fare una cosa del genere che non siano le prestazioni
grafiche,e mi sembrano tutt'altro che una priorita se paragonate alla
stabilita del sistema.Per come la stiamo mettendo sembra che X sia da
buttare perche gira in user space ... ricordiamo per cortesia che e'
tutt'altro che cosi :-)


 le NtUser, una per una, assicurandomi di sapere cosa stessi dicendo.
allora ricomincia da capo con piu calma.
"In Windows NT 4.0, much of the Win32 graphical user interface (GUI)
subsystem—the Window Manager, Graphics Device Interface (GDI), and
related graphics drivers—were moved from a body of code that executed in
the csrss.exe subsystem process to a kernel mode device driver
(win32k.sys)."
indovina chi lo ha detto ...


 e perche non ha alcun senso ? 
Perchè l'X-server sta sul client, ma ciò che è più sorprendente è che la 
gente continui a sostenere che è l'architettura più furba possibile.

 l'architettura piů furba possibile.
Dipende da quello che uno ci deve fare.
Daltronde dire "non ha alcun senso" e' un po' integralista, non ti pare?
Alessandro.

 gente continui a sostenere che č l'architettura piů furba possibile.
e questo ti permette in una rete a terminali di non delegare tutte le
operazioni sul server,le applicazioni girano sul server ma le operazioni
di disegno finestre etc .. sono delelgate ai client,senza contare la
portabilita. Dov'e' il problema scusa ?


 che ne so) il collo di bottiglia.
Mi sembra che la situazione sia un po' confusa: stai sostenendo che non e'
questione di kernel o user mode ma un problema di protocollo, o sbaglio?
Alessandro.

 contare la portabilita. Dov'e' il problema scusa ?
Che l'applicazione gira sul server ma dipende in modo vitale dal client. 
 

 Daltronde dire "non ha alcun senso" e' un po' integralista, non ti pare?
Non abbiamo nemmeno parlato delle applicazioni grafiche eseguite sulla 
stessa macchina...
(*) manco voglio nemmeno citare il client per servizi terminal di windows.

 windows.
Infatti, quello e' un concetto innovativo e rivoluzionario...
Alessandro.

windows.
usa ssh o vnc se vuoi dei semplici terminali,X e' fatto per bilanciare il
carico del lavoro tra il terminale ed il server,le operazioni grafiche
sono lasciate ai client che montano un X-server che interfaccia le
applicazioni remote (quelle che esegui sul server remoto) al tuo
hardware,terminal server che io sappia non fa altro che mandare un mappa
bit a bit dello schermo,tutte le operazioni sono a carico del server,se
hai molti terminali colllegati allo stesso server la soluzione X e' piu
consona,ti evita di sovraccaricarlo.Non e' perfetto .. ha i suoi pro e i
suoi contro,ti permette ad esempio di avere diverse applicazioni lanciate
su server diversi in maniera assolutamente trasparente
all'utente,puoi scrivere applicazioni che funzionino solo su un computer
remoto [¹].. etc ..chiaramente si comporteranno come se fossero in locale,cioe se
killi X killi anche loro.
[¹] se tipo hai 40 impiegati che usano la stessa applicazione su un server
puoi rendere la cosa trasparente.


 Boh, ma di che cosa stavamo parlando?
vedi sopra. 

Non parlo di un server come X siamo intesi.
Un sacco di volte la gente odia X ma pensa a kde & gnome.
Come dicono gli sviluppatori di B.E.O.S. rimmarreste stupiti dalla
reattività di X se ben gestito e senza ettari di fuffa colorata mal
fatta :)
Credo che iul vero problema di X fosse che non è multithreaded, ma
forse sto inventando. E tanto, ormai siamo troppo avanti, non c'è più
possibilità di ritornare indietro, troppa legacy :/

 diffusa e IMHO sbagliata.
mi piace molto 
www.directfb.org
 , le applicazioni girano su framebuffer.

 L'unica ragione plausibile è la seguente: _è_ _troppo_ _tardi_.
ecco, bravo, i bambini piccoli devono andare a letto....
porca miseria, ho letto i tuoi post e non c'è una minima giustificazione
tecnica della tua affermazione....

 Grafico non sembra pure a voi ?
non direi una scelta ideologica, piuttosto di design.

 orrore.
idem

 per carità. Questo va giusto bene per giocare a Pacman sul cellulare.
anche un po' di più. va bene per molti sistemi mebedded, dove far girare
un server X e un windowmanager richiederbbe risorse hardware maggiori.



mi sembra che valga lo stesso anche in altri sistemi distribuiti anche 
sotto win. se chiudi / stacchi / rompi il client cosa pretendi? Uccidere
il server X è come staccare il kernel di windows....

 assolutamente trasparente all'utente,
Load balancing.  

 il server X č come staccare il kernel di windows....
Ecco, bravo: il problema č che ho il server X sul client, che se lo uccido 
č come staccare il kernel di windows. E' la ragione della mia affermazione 
di cui sopra.

 Visto che il programma gira sul server, 
Un momento, ma stai parlando di programmi che usano X?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 Un momento, ma stai parlando di programmi che usano X?
Si, certo. La "critica" è rivolta ad essi.


Ed allora stai sbagliando tutto, perché il programma non gira sul 
server, ma sul client. Se cade la connessione all'improvviso non succede 
niente, almeno che non vada in timeout.



No, questo e' stato aggiunto "abusivamente" (leggi il subject :-).
Alessandro.


Indubitabilmente (anzi mi sembra che sia un esempio straordinario di
longevita', direi).
Alessandro.

 niente, almeno che non vada in timeout.
mmm... niente? Se cade la connessione ti crepa il programma, altrochè :-)

 mmm... niente? Se cade la connessione ti crepa il programma, altrochè :-)
Se stacchi il filo, e la connessione non va in timeout, non succede 
niente di niente.


 Capita in molte applicazioni client-server, non solo X.
Si, ma non capita in molte applicazioni distribuite (come vorrebbe essere) 
:-)

 niente di niente.
Beh, connessione tcp, cadere la connessione per me significa che il socket 
non sia più valido e non importa proprio che vada in timeout. 
In ogni modo, sotto altri sistemi conosciuti e a suo modo disprezzati io 
sono libero di disconnettere volontariamente il client, spengerlo del 
tutto, prenderlo a mazzulate, poi riconnettermi ad un'altro terminale e 
trovare il mio programma che gira ancora come se niente fosse. 

 trovare il mio programma che gira ancora come se niente fosse. 
Prima di tutto X non è nato per applicazioni distribuite, è nato per 
applicazioni remote. In secondo luogo potrebbe essere perfettamente 
possibile, a patto di modificare l'implementazione della Xlib, gestire 
eventuali disconnessioni, vuoi casuali vuoi a forza, da parte del 
server, ma di questo non ne sono sicuro.


 protocollo, o sbaglio? 
con il server grafico in kernel mode, che gira nello stesso contesto di 
ogni processo client, non è necessaria alcuna serializzazione. Però, se 
la serializzazione viene imposta, non c'è scampo. E a me risulta che in 
X la serializzazione sia obbligatoria, indipendentemente dal trasporto, 
tanto che ricordo alcuni toolkit implementare un proprio buffer comandi 
per non chiamare il server troppo spesso. Non che dall'altra parte vada 
tanto meglio, eh. Anzi, è l'esatto opposto: rigorosamente ancorato alla 
macchina locale e alla gestione di processi, thread e memoria virtuale. 
Meno portabile di così, non saprei immaginarne. Per questo l'unico modo 
per avere un display remoto in Windows è la periferica video remota (ma 
funziona sorprendentemente bene)
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 contesti diversi,mi sfugge il problema.
č vero, ti sfugge. Perchč la versione Windows di QT non č open source?


 allora ricomincia da capo con piu calma.
mah, e dire che per un attimo ho pensato fossi uno bravo. E invece solo 
un altro copincollista. Pussa via, torna quando hai un cervello tuo


 anche un po' di più. va bene per molti sistemi mebedded,
è quello che intendevo :-) ho solo voluto dirlo in modo colorito


 bit dello schermo,
aaah, ma tu, proprio tu, uno come te, che si permette di insegnare a me 
come funziona win32k.sys, e poi mi fa una cappella del genere? roba che 
sa anche il lustrascarpe di Bill Gates? Terminal Services usa un driver 
video che spedisce, tramite un protocollo di RPC (Virtual Channels), le 
*chiamate DDI* ad un client remoto. Il framebuffer sta sul client. E le 
bitmap vengono trasferite solo se richiesto esplicitamente (esempio: le 
icone, lo sfondo del desktop, ecc.). Quello che dici tu è VNC, che è, a 
tutti gli effetti, un dumb framebuffer remoto


 server, ma di questo non ne sono sicuro.
Fai bene a non essere sicuro :-) perchè stando così le cose non è proprio 
possibile. Oddio, probabilmente è possibile fare in modo che se la 
connessione si interrompe l'applicazione "ritenta" a connettersi con 
l'Xserver finchè non ci riesce, o rimane appesa, ma ci sarebbe da fare 
veramente delle grasse risate. Praticamente basta che nel frattempo 
qualcun'altro si presenti "piacere, sono 192.168.0.12" e l'applicazione gli 
spiattella tutto quello che stavi facendo dandogli l'accesso del *tuo* 
utente senza nessun criterio di sicurezza.
Permetterai che con RPC le cose siano *leggermente* diverse. 
 

 utente senza nessun criterio di sicurezza.
Suvvia, credi davvero che X non abbia cognizioni di sicurezza?


 Suvvia, credi davvero che X non abbia cognizioni di sicurezza?
Io credo a quello che vedo.
Sai come funziona, no? Tu ti connetti come utente "root" (esageriamo, per 
enfatizzare la cosa) e lanci l'applicazione in modo che ridiriga l'i/o 
sul display identificato dalla macchina 192.168.0.12 (host autorizzato, 
quindi tutto a posto). L'applicazione parte e si connette all'Xserver 
suddetta macchina, senza ulteriori autenticazioni, giusto? Nessun 
problema, glie l'ho detto io. Il programma che compare sull'host ha i 
privilegi di root sulla macchina remota.
Se interrompi la connessione e poi pensi di ripristinarla, non puoi 
dimenticare che la connessione fra app e xserver non prevede alcuna 
autenticazione diretta. Stando così le cose sarebbe ovviamente una falla 
abnorme. Con un protocollo autenticato magari ne riparliamo.
Con il terminal server saprai meglio di me, prima di tutto ti chiede chi 
sei e poi (se vuoi) ti restituisce la tua sessione.

Non si mette in dubbio X ma si sta dicendo (o per lo meno lo dico io) che 
alcune delle funzioni di cui x č dotato (esempio la struttura clien server 
č inutile) ad un utente medio che al massimo usa un PC per far girare 
OpenOffice non servono a nulla e che con una gestione grafica inclusa nel 
kernel si velocizzerebbe il tutto ci sarebbe un unico modo di gestire la 
stessa (esempio le code eventi  tipo mause tastiera ecc) .... 

 chi sei e poi (se vuoi) ti restituisce la tua sessione.
In Gnome ho sentito parlare di "session manager" che sarebbe responsabile
del ripristino delle applicazioni nello stato in cui erano alla chiusura
della sessione (penso che riguardi solo la disposizione delle finestre ma
non ne sono sicuro).
Dubito che sia stato concepito per gli scopi che tu proponi, ma con un po'
di buona volonta' potrebbe andarci abbastanza vicino.
Per avere l'autenticazione basta che si consideri l'uso di xdm o simili e
avresti l'analogo del "Terminal Services" di Windows (con il quale, se non
erro, non puoi far eseguire una singola applicazione su schermo remoto ma
solo un'intera sessione).
Altra osservazione: non e' affatto detto che in caso di interruzione della
connessione lasciare il programma remoto in esecuzione sia sempre l'idea
migliore (ovviamnete non e' detto neanche il contrario :-).
Alessandro.

 bit a bit dello schermo,tutte le operazioni sono a carico del server,
Aaargh, dillo windows xp e al suo desktop remoto quando sono a 56k bit :)
Non e' come dici (tradotto: juliet non e' pazza, o perlomeno, e' pazza  ma
ha ragione.).
Saluti.

 sicura di che altro. Credo sia pių o meno lo stesso ruolo dell'X-server
Non facciamo paragoni profani... al massimo, il kernel di Linux gestisce
l'AGP ed il DRI, non c'e' nulla nel kernel che possa essere paragonato a
"gestione di oggetti grafici" o "code di messaggi".
ciao
-- 
Marco Ermini
http://macchi.markoer.org
 - ICQ UIN 50825709 - GPG KEY 0x64ABF7C6
Never attribute to malice that which is adequately explained
by stupidity. (Hanlon's Razor, corollary to Finagle's law)


E' vero, ci saranno primitive per il riempimento dei rettangoli, copia e
spostamento delle supercici, gestione dei font. Ma supporta anche direct3d?
No, perche se no non e' molto meglio di X :-)
Alessandro.

 è vero, ti sfugge. Perchè la versione Windows di QT non è open source?
chiedilo alla trolltech,comunque per privati ci sono in versione trial di
30 giorni,se hai voglia di provarle ...
-- 
          "chown linux:users /world"
"E se i filosofi a cena mangiassero colle mani ?"

 a tutti gli effetti, un dumb framebuffer remoto
non solo vnc,viene usata cme tecnica da altri tool di amministrazione
remota.


 autenticazione diretta. 
prevede l'autenticazione sulla macchina remota di chi lancia
l'applicazione ... non vedo limiti di protocollo nel salvare una sessione
e lanciare un login in caso di riconnessione ... certo te la dovresti
giocare un po coi tempi (che so l'xclient dopo y tempo che il server non
risponde salva la sessione e si aspetta che il server si
riautentichi).
se parliamo di sicurezza mi vengono in mente problemi peggiori di X ...
ad esempio il fatto che tutti dati passino in chiaro o il fatto che abbia
bisogno di una porta aperta per le connessioni e una per il login (se non
si usa telnet) ma tunnellando tutto in ssh si risolvono entrambi.


No, perche se no non e' molto meglio di X :-)
Fidati, e' moooolto meglio di X.
Sia a livello di prestazioni che di funzioni offerte.
Ciao
-- 
Francesco

nell'utilizzo di applicazioni distribuite fai pure ...
Insomma, a parer mio E' un gran difetto.
Con TS posso spegnare il pc in ufficio, ricollegarmi da casa e mi
ritrovo la mia applicazione che nel frattempo sta ancora girando.
E' questo e' un gran vantaggio.
Ciao
-- 
Francesco

Ciao
Be ma se proprio dobbiamo essere precisini su Windows parlerei piů di
Cytrix che di Terminal Services non fosse altro perche il lavoro e il
loro e su Windows 2000 ne trovi una versione ridotta
MAX
- 
   MAX
-- 

loro e su Windows 2000 ne trovi una versione ridotta
Ovvio, si sono comprati la tecnologia da loro.
Comunque su .net hanno implementato altre funzioni e lavorato
ulteriormente sul protocollo per renderlo ancora piu' veloce.
Inoltre posso fare il bilanciamento del carico gia' nella versione
server standard mentre prtima mi ci voleva per forza l'advanced.
Non so se usando .net abbia ancora senso comprare anche citrix, ma ho
i miei dubbi..
Ciao
-- 
Francesco

Comunque su .net hanno implementato altre funzioni e lavorato
Si pero hanno acquisito i diritti sulla tecnologia non sui sorgenti di
conseguenza tutte le implementazioni vengono ancora fatte da Cytrix
per conto di MS.
Questa da un congresso che Cytrix ha fatto qua a Milano circa un paio
di mesi or sono.
- 
   MAX
-- 

 le prestazioni aumentano
Le prestazioni aumentano per un mucchio di motivi. Qui vicino ho una
Indingo2: come potenza di calcolo sembra un 386, come velocita' grafica
da i punti (e parecchi) a qualsiasi P4 2Ghz con qualsiasi scheda grafica
in questa stanza).
Se non fosse che all'epoca e' costata 70 M£...
C:\>iao Angelo

 non basta un login ?
e/o un altro meccanismo di autenticazione


di mesi or sono.
Mica mi dispiace che non si MS a farlo ;-))
Pero' al convegno di presentazione di Citrix XP l'anno scorso mica
c'e' l'hanno detta sta cosa..
Ciao
-- 
Francesco




Un altra cosa che hanno sostenuto e che Cytrix riceve le royalties
delle licenze che MS vende inoltre erano anche presenti alcuni
commerciali di MS Italia che prensentavano alcune applicazioni e "casi
di successo".
MAX
- 
   MAX
-- 

Non si mette in dubbio X ma la mia domanda era scaturita dal fatto che 


solo un'intera sessione).
Ni, da impostazioni utente o TS puoi far partire obbligatoriamente una
applicazione al momento del logon, l'utente vede solo quella e non
tutta la sessione, al momento della chiusura dell'applicazione si
chiude ovviamente anche la sessione.
Ciao
-- 
Francesco

 servizio.
il problema nasce da un fraintendimento di termini.
C'è il server X che gira sui client e poi c'è l'application server, che
non ha nulla a che fare col server X. Se li si chiama solo server è
_molto_ facile fare casino coi nomi....

 stessa (esempio le code eventi  tipo mause tastiera ecc) ....
qua non ho capito che vuoi dire


 nell'utilizzo di applicazioni distribuite fai pure ...
Un difetto? No, macchč... č un pregio! :-)

 :-). 
Infatti esiste l'opzione logoff on disconnect.

 chiedilo alla trolltech,
te lo dico io. Perchč la potente xlib fa solo quello che dice il nome e  
non quello che gli vorresti attribuire. Ergo, la versione per Windows č 
la piů costosa anche per loro
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 remota.
ma certo, anche nel potente BO2K funzionava così


 gravoso su piattaforma intel e su sparc/mips/alpha etc .. ?
non č il context switch. E' la serializzazione-deserializzazione


 o "code di messaggi".
l'ultima volta che ho fatto partire un Linux ho letto distintamente nel 
log del kernel la partenza di ben due sottosistemi di IPC. Avrò sognato
Suvvia! non stavo parlando di questo. Era per dare un metro di paragone 
sul "cosa", non sul "come"


 direct3d? No, perche se no non e' molto meglio di X :-)
Ti garantisco che è molto di più e molto meglio.
La discussione me lo ha ampiamente confermato.

 _molto_ facile fare casino coi nomi....
Il fraintendimento dei termini si supera, basta volersi capire. In realtà 
il fraintendimento è tecnologico. E' chiarissimo che ci sono due server 
(comunque si chiamino) ma i client chi sono?
Se io devo usare una applicazione remota con gli stessi limiti di una 
applicazione client, perchè non usare direttamente una applicazione client? 
Per suddividere il carico fra due macchine, come dice steve? Non mi 
convince affatto. Specialmente se si fanno confronti con altre tecnologie e 
si vede quali risultati sono auspicabili sulle applicazioni distribuite.

 client?
Perche' la macchina locale e' molto meno potente di quella remota.
Alessandro.

Marco Sarti wrote:
 > [...]
Marco, 'ca parlamme e nun ce capimme :)
Il client è l'applicazione grafica, il server è quello che riceve le 
richieste dal client di disegnare sullo schermo.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 entrambi. 
In una rete privata non me ne può fregare di meno se i dati passano in 
chiaro. Su internet ovviamente me ne frega a prescindere, nel senso che non 
permetto nemmeno a rpc di viaggiare in chiaro o al di fuori di vpn. 

 wrote in news:b0i1e0$8rm$
1...@lacerta.tiscalinet.it
:

Meno potente di un thin client? 

 Meno potente di un thin client? 
La risposta era sbagliata, quella giusta è che la macchina remota è 
_più_ potente di quella locale. X è nato quando c'era il supercomputer 
che faceva i calcoli, ed il computerino personale che li visualizzava, 
spesso a centinaia di chilometri dal supercomputer. L'implementazione 
magari non è delle migliori, ma l'idea non è per niente da buttare.
Per la cronaca, Photon, la microgui di QNX, permette di fare tutto 
quello che fa X e anche di più, il tutto utilizzando il message passing 
di QNX Neutrino, che è network transparent: architettura client-server, 
e le prestazioni sono di tutto rispetto.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 _più_ potente di quella locale.
Oops, in verità la risposta era giusta, non ho fatto altro che ripeterla 
pure io, ma devo essere incappato nella stessa svista nella quale sei 
incappato tu: il thin client è la macchina _locale_.


 Marco, 'ca parlamme e nun ce capimme :)
Su questo non c'č dubbio, visto che io sto dicendo che č una architettura 
poco utile mentre tu stai continuando a ripetere che non ho capito com'č 
questa architettura...

 magari non è delle migliori, ma l'idea non è per niente da buttare.
Ci sono idee migliori.

 questa architettura...
Se continui a confondere server con client...


 Ci sono idee migliori.
Anche 30 anni fa?


 non quello che gli vorresti attribuire. 
e cosa non farebbe che io gli vorrei attribuire ?
-- 
          "chown linux:users /world"
"E se i filosofi a cena mangiassero colle mani ?"

 in cui fanno una chiamata. E la xlib dovrebbe nascondere la differenza
non basterebbe solo velocizzare la trasmissione client-server ? non il
client che fa anche da server ma il client che comunica con il server in
maniera diversa,chiariamoci ... secondo te il problema sta nel protocollo
o nel sistema client-server ? se le comunicazioni client-server avvengono
tramite memoria condivisa dov'e' il problema ?


 permetto nemmeno a rpc di viaggiare in chiaro o al di fuori di vpn.
direi che le opzioni per una connessione sicura non mancano ne in TS ne in
X.



:-)
Alessandro.

 Anche 30 anni fa?
Fra "30 anni fa" e oggi sono passati 30 anni. Se volevo riferirmi al 1973
dicevo "C'erano idee migliori".

 dicevo "C'erano idee migliori".
Mai sentito parlare di "legacy support"? Ed in ogni caso, devi provarlo 
con benchmarks che X fa schifo, non con parole.


 risultati sono auspicabili sulle applicazioni distribuite.
beh, si spera bene che quello che è venuto dopo sia meglio (cosa che, in
generale, non è sempre vera.... :-) )

 Se continui a confondere server con client...
No, niente da fare. Connection refused. 
 

 dov'e' il problema ? 
dimmelo tu. Pensaci un po' su
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 con benchmarks che X fa schifo, non con parole.
Benchmark? Ma per piacere. Questo tuo modo di discutere mi ha deluso. X non 
fa schifo, perchè? Perchè oso dire che ci sono dei limiti oggettivi (non 
prestazionali, che me ne frega?) a distribuire le applicazioni con questa 
tecnologia? Limiti che sono ampiamente superati? Bene, se per "fare 
schifo" intendi questo sappi che non ho bisogno di provarlo con nessun 
benchmark (?), se invece intendevi qualcos'altro vuol dire che non stavi 
discutendo con me.

 riduce la quantitą di manutenzione che il sistemista deve sbobbarsi.
Sicuramente, ma allora lode al terminal server :-) che riduce la 
manutenzione di un'altro ordine di grandezza. 

 la più costosa anche per loro
le xlibs fanno quello che devono fare ... chiaro che per usarle hai
bisogno di un implementazione di X,se quello che cerchi sono delle
librerie multipiattaforma,cioe che funzionino sia su unix attraverso le
xlibs sia su altri sistemi attraverso le rispettive api le qt fanno per
te,ma certo con x non c'entrano un tubo,almeno su altre piattaforme,le
xlibs fanno questo ma prescindono dal fatto che tu abbia gia
un'implementazione di X,e ce ne sono per praticamente tutte le piattaforme.


 ma certo, anche nel potente BO2K funzionava cosě
da quel che so io anche pc/remotely anywhere e compagnia bella.


 nel sistema client-server
hai detto prima che il protocollo era il collo di bottiglia ...
e anche se il problema fosse l'architettura client-server che
miglioramenti speri di ottenere implementando parte del server in kernel
space ? (visto che e' l'argomento del topic)


 soluzioni Sun (tanto per non parlare sempre di linux). 
no no parliamo pure di linux :-P
http://www.ltsp.org/


 
http://www.ltsp.org/
http://www.ltsp.org/documentation/ltsp-3.0-4-it.html#AEN53
Fino ad un certo punto č stato *molto* interessante. Fino al punto 29 per 
l'esattezza :-)
Va beh, ormai l'avete capito cos'č che non mi va giů, specialmente parlando 
di "thin client".

 di "thin client".
dai un'occhiata a xmove,fa piu o meno quello che chiedi (ti permette di
spostarti di postazione mantenendo le tue applicazioni a girare sul
"server" [ą](inteso come quello che fa girare i client eh ..)
[ą] quello che fa e' piu o meno creare uno pseudo xserver su cui far
girare i client finche non ti colleghi con un altro server


 ha ampiamente confermato.
una curiosita ...
ma terminal server gestisce la stesa sessione su piu display ? e diverse
sessioni che lavorano sulla stessa schermata da postazioni diverse ?
(lavori di gruppo su immagini ad esempio)
(senza ovviamente dover dare l'account di chi lancia l'applicazione eh ..)


 diverse ? (lavori di gruppo su immagini ad esempio)
Si può ottenere lo shadow di una sessione, se si hanno i diritti. Utile per 
amministrare/guidare/istruire un utente, non direi per lavorare insieme.

 No, non che io sappia. 
Con QNX puoi fare pure quello, e usa un approccio client-server 
trasparente all'applicazione.


 manutenzione di un'altro ordine di grandezza.
potrei anche darti ragione... Insomma, se si escludono i virus direi che
siamo li'. :-P
per quanto queste soluzioni hanno sempre un grosso problema: quando hai
troppi client ti si intasa la rete... Qui a ingegneria a padova abbiamo
una sorta di par condicio: linux, solaris e win sono tutti e tre belli
incaprettati.

 Qualsiasi cosa in kernel mode può tirare giù il sistema, non solo la GUI.
Si', ma... senza dimenticare che piu' una porzione di codice e' estesa e
complessa, piu' e' soggetta a bug... li sta il discorso e... il rischio.   :-)
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.

 Si chiamava Berlin, ma adesso ha cambiato nome...
Ora si chiama Fresco. Un altro progetto simile e` picoGUI (se non ho
i neuroni completamente fusi). Cmq, il problema piu` grosso di questi
due progetti e` che vogliono reinventare la ruota da zero (in altre
parole, niente compatibilita` con X)
Henryx
-- 
GnuPG fingerprint = 42F9 521B 63C7 89FE 354C  89FA 4E49 3E2D 2EB6 B014

 parole, niente compatibilita` con X)
Più che altro, sono progetti pensati (soprattutto picoGUI) per il
mercato embedded, dove X non ha alcun senso. Ma, se non sbaglio, sia
Fresco che picoGUI non hanno il supporto per dei widget set come GTK
e QT, quindi devono usare i propri.
Se sviluppasero un supporto per le librerie usate su X, potrebbero
essere molto interessanti anche per il desktop...
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)              [ 
http://digilander.iol.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

e QT, quindi devono usare i propri.
forse directFB č quello che serve? ;)

 forse directFB è quello che serve? ;)
picoGUI non si basa proprio su directFB?


picoGUI non si basa proprio su directFB?
Boh, credevo di no. 
E soprattutto mi basavo sul mshg porecedente, le GTK/fb dovrebbero
esistere da tempo, oltretutto c'era anche un layer di emulazione delle
xlibs in lavorazione. 
Ma forse devo solo smettere di frequentare i newsgroup mentre
programmo in java (sic!)

 sul "cosa", non sul "come"
vabbene...
-- 
Marco Ermini - L.U. #180221
http://macchi.markoer.org
 - ICQ 50825709 - GPG KEY 0x64ABF7C6
Never attribute to malice that which is adequately explained
by stupidity. (Hanlon's Razor, corollary to Finagle's law)

 frattempo sta ancora girando. E' questo e' un gran vantaggio.
Puoi fare la stessa cosa con Linux utilizzando una componente VNC server
da far partire come processo sulla macchina da amministrare.
Comunque, il fatto che sia un pregio o un difetto dipende dal sistema. Su
Windows e' certamente un pregio, perche' fai tutto dalla GUI, quindi
ritrovarla nello stesso stato in cui l'hai lasciata fa comodo. Su Linux
non ci sono grandi applicazioni da lasciar girare in batch che funzionano
*soltanto* tramite GUI, che adesso mi sovvengano, percio' lasciare un
processo VNC server con relativo XWindow e WM a girare sul server puo'
essere solo un carico inutile.
ciao


 nonostante questo non lo ritengo sto gran collo di bottiglia
[...]
Ti preclude la possibilita' di... fare i giochini :-)
Per applicazioni grafiche molto veloci devi utilizzare il DRI del kernel
accoppiato alle corrispondenti librerie DRI di X Windows, in modo da
bypassare X nel rendering di specifiche porzioni dello schermo.


 Sia a livello di prestazioni che di funzioni offerte.
Io non direi che e' "moolto meglio". Sono cose diverse. X-Window e'
abbastanza paragonabile, anche se terminal server e' sicuramente una
tecnologia piu' "nuova" (e soprattutto, come tutte le cose belle di
Microsoft, non l'ha fatta Microsoft). Anche X Windows, se utilizzato con
dei server "evoluti", supporta le estensioni per
X Window e' estremamente migliore di TS a livello *applicativo*, perche'
e' gestibile in modo molto piu' flessibile e puoi implementare il
protocollo in svariati modi, distribuendo il carico ed i desktop in modo
piu' flessibile (es. su varie CPU ecc.). Per questo, dovendo implementare
un sistema di gestione distribuita di desktop per diversi utenti, e
sperando di implementare un qualcosa di un minimo fault tolerant,
sceglierei sicuramente X Windows e non TS.


sceglierei sicuramente X Windows e non TS.
Evidentemente non conosci bene TS.
Le funzioni fault tolerant e di distribuzione del carico sono
supportate in modo nativo e trasparente alle applicazioni:
http://www.microsoft.com/windows2000/techinfo/howitworks/cluster/nlb.asp
Senza contare che l'RPD e' comunque piu' performante del protocollo di
X, cosa che gli permette di funzionare anche via PSTN e con wan a
bassa velocita', cosa praticamente impossibile con X.
Ciao
-- 
Francesco

essere solo un carico inutile.
Le applicazioni Office dove le metti?
A me, personalmente, starebbe un poco sulle balle riscrivermi un
documento di 4 pagine perche' magari mi e' caduta la linea telefonica
che mi collegava al server.
Ma evidentemente sono un caso particolare ;-)
Ciao
-- 
Francesco

 perche' improprio? sono socket unix
mi e' capitato di prendermi degli accidenti per non averli chiamati "unix
domain socket" ma solo "socket unix" ... nel dubbio ho specificato :-) 


 e' caduta la linea telefonica che mi collegava al server.
ho gia detto in un altro post che si puo fare anche con X ... basta creare
uno pseudo X server (sul server) e farci girare le applicazioni finche non
cambi postazione (man xmove)


 tu ti sbagliassi con qualcos'altro... ;-)
ho la faccia di una che si sbaglia? <fa boccacce>
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 ecc.).
e aridanghete con la storia del "flessibile". Potessi avere un eurocent  
per ogni volta che ho letto abusare di quella parola, Bill Gates, oggi, 
sarebbe un mio dipendente. Se ci limitiamo agli abusi in contesto open-
source, dovrei probabilmente accontentarmi di essere sua collega
No. Semplicemente, no. Stai confrontando due implementazioni. Tienilo a 
mente sempre. Una cattiva implementazione è un problema oggi, mentre un 
cattivo design sarà un problema quando meno te lo aspetterai. X-Windows 
ha un design un po' anacronistico - oggi, la gente vorrebbe farci anche  
il caffè, ma allora non era previsto - e invece di correre ai ripari lo  
si asseconda, solo perchè le implementazioni attuali sono ben fatte. E' 
chiara la differenza?


 lasciata fa comodo.
ci risiamo con il giornalismo di bassa lega. Demonizzazione del nemico, 
sviamento del discorso su campo favorevole, scenario non disinteressato 
e comunque poco realistico. Direi che non manca niente. Seriamente. C'è 
uno sfracello di ragioni per voler ritrovare la sessione di lavoro così 
come la si era lasciata, quasi tutte psicologiche (come fate a lavorare 
se appena acceso il computer non avete già l'editor aperto nello stesso 
punto dello stesso file di prima di andare a dormire?)


 ho la faccia di una che si sbaglia? <fa boccacce>
Per me non hai una faccia e basta ;-)
ciao


 punto dello stesso file di prima di andare a dormire?)
Hey non e' che ti stai scaldando troppo? guarda che non stavo parlando in
senso denigratorio. Cosa vuoi che me ne freghi del paradigma di
funzionamento di Windows? ci sono tante cose irrazionali al mondo, se
debbo usare per forza una interfaccia verde con cursore bianco piuttosto
che una nera con i caratteri verdi, ma non credi ci siano cose piu'
importanti nella vita di cui scandalizzarsi? :-)
E poi, senti... ma tu una email su Windows come la scrivi? installi
cygnwin e mutt per usare soltanto la linea di comando?
Ed al di la' di come fai tu, il 99% degli utenti Windows utilizzera' un
qualsiasi MUA grafico. E non dubito che se uno inizia a battere un
documento Office in ufficio gli possa far piacere riaprirlo a casa e
ritrovarlo nello stesso stato in cui l'ha lasciato in ufficio (ammesso che
Win intanto non sia crashato da solo senza motivo ;-)


 Ma evidentemente sono un caso particolare ;-)
Certamente, ma tu affronti tipologie diverse di utilizzo. Un conto e' il
telelavoro telefonico, un conto e' la gestione di thin client aziendali.
Fatta questa precisazione hai assolutamente ragione, il tuo modo di
utilizzo non e' certo un caso particolare.


 velocita', cosa praticamente impossibile con X.
X "normale" forse no, ma X tunnellizzato in SSH non credo proprio che sia
molto diverso dall'RPD.
E comunque, l'ultima volta che una ditta in cui io lavoravo da consulente
ha voluto provare un "cluster" Microsoft l'ha rispedito indietro perche'
*nativamente incompatibile* col protocollo ATM... molto utile da usare da
usare "via PSTN e con wan a bassa velocita'" non credi?


 chiara la differenza?
Hai presente cosa sono le MIT extension? hai presente tutte quelle opzioni
che ti appaioni quandi cerchi di far andare piu' veloce il Hummingbird?
sono la dimostrazione che il protocollo di X e' stato cambiato e
potenziato negli anni un sacco di volte...
E poi, guarda che design ed implementazioni hanno a volte ritorni ciclici.
Un tempo si affittavano cicli di CPU su un server in un'altra regione, e
con Unix si sono inventate le stazioni X;  poi si e' passati ai personal
computer, e da li' si sono diffuse le reti locali, e' sorta la necessita'
di centralizzare l'amministrazione delle risorse... e si e' tornati ai
thin client, implementazione sicuramente molto piu' evoluta ma degli
stessi protocolli, magari oggi tunnellizzati, criptati e compressi...


telelavoro telefonico, un conto e' la gestione di thin client aziendali.
Perche', quelli non scrivono lettere? ;-)
Ciao
-- 
Francesco

usare "via PSTN e con wan a bassa velocita'" non credi?
Cosa era incompatibile, l'RPD?
Ciao
-- 
Francesco

usare "via PSTN e con wan a bassa velocita'" non credi?
Cosa era incompatibile, il cluster (???) e l'rpd?
Ciao
-- 
Francesco

 è vero, ti sfugge. Perchè la versione Windows di QT non è open source?
Perche' dentro c'e' nascosto il Bubuti.
-- 
                    Davide Inglima a.k.a. Gatto Feroce
           "Mana is rapidly disappearing from the world... Even the"
              "mana tree has begun to wither." Seiken Densetsu 3
 
http://web.tiscali.it/inglima/davide
                       mailto:
hades...@libero.it