Am Fre, 2003-07-11 um 18.45 schrieb Jay R. Ashworth: > On Fri, Jul 11, 2003 at 10:39:18AM -0700, Alan Coopersmith wrote: > > Jay R. Ashworth wrote: > > >>>On Fri, Jul 11, 2003 at 03:03:59AM +0200, Rene Bartsch wrote: > > >>>>>From SUN I know you can close the X-session without stopping > > >>>>processes/programs/window-manager running on the server (just pull off > > >>>>your smartcard from one terminal and put it into another one and keep on > > >>>>working. The processes and window-manager have kept running in > > >>>>background on the server). > > > > > > Well, that's fine, but if the Xserver is on the terminal, and you want to > > > shut it down, I see no obvious way that you can keep all the clients > > > connected to it from falling over. I'm not sure what Sun is playing at, but > > > I'm pretty sure it's not 'traditional X'. > > > > Actually it is. It's the same Xserver that runs on normal workstations. > > The difference is a SunRay is NOT an X-terminal. It's a graphical dumb > > terminal. Conceptually, a SunRay is a video board and USB hub connected > > via ethernet instead of PCI/AGP. The Xserver runs on the server machine, > > so a server with 200 SunRays has 200 Xsun processes running. > > He didn't *say* SunRay.
I'm not sure if it's a SunRay. The system is about 4 years old, one server and 20 terminals, which are very light-weight (I can remind our Sun-admin once said Sun uses a special protocol which sets each bit one by one on the terminal - assumingly what you called DDX some lines down). So it seems VNC-like. > > That's another thing entirely -- almost exactly the same as Xvnc, from what I > understand. > > > The magic of SunRay hotdesking (moving sessions from one terminal to another) > > is that as far as X is concerned, nothing changes. The SunRay DDX handles all > > of that. It keeps local backing store (ala Xvfb/shadowfb), and sends updates > > to the appropriate SunRay terminal. If you pull your smartcard out of terminal > > A, it simply stops sending those updates and only updates the local backing > > store. If you then plug into terminal B down the hall, it dumps the entire > > backing store to terminal B, then goes back to normal operation sending updates > > to that terminal instead. > > Yeah, that's almost 100% identical to what I set up with VNC for my client. > I used NIC's with a slightly modified boot CDROM as terminals, but they're > toast now of course -- but any acceptable pizzabox is around the same price. Ok, here's what I'm going to do: I want to setup a small, multimedia-capable terminal-net to have only one machine to maintain. This could be used in larger homes, living-communities, workgroups, ... The server should run linux (currently using Mandrake 9.1) with KDE and the terminals should either use PXE/TFTP or eventually compact flash (which would increase maintenance) for booting a slim, static LFS with BusyBox, XFree and some deamons/servers like artsd. The machines will be x86 32- or 64 bit. In the server there will be a lot of storage (3/4x 160 or 320 GByte IDE-Raid) and optionally DVB-cards with vcr- and streaming-applications, scanner, printer ... For sound I'm going to use ARTS, as it is provided with and embedded into KDE (but as it seems it does not support AC3/DTS). For 3D-support I want to use Nvidia-GPUs in the terminals (Shuttle FN41-boards with NForce2, SPDIF, USB 2.0, 100 MBit/s NIC for Athlon/Duron in FlexITX-format are very interesting for that purpose). I have been very impressed using Nvida GLX-module only needed 6 MBit/s bandwith for a OpenGL-simulation (test-client was Celeron500 with Geforce256 at full load). So I need XDMCP to have an evironment like working directly on the server. But the problem is power-management and security. To keep current, heat and noise low I want to use suspend-to-ram on the terminals (and logging out the user when going to potty, of course). But the tasks and processes started by the user should go on without additional user-interaction (withpassword/smartcard-protected screenserver after five minutes and suspend-to-ram after 10 minutes and moving to another machine should be possible). -- Rene Bartsch Faculties MNI Computer Science 8th Semester FH Giessen/Friedberg, Germany Facsimile/Phone: +49 7 00/72 27 87 24 Mail: [EMAIL PROTECTED] _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
