Re: Remote Desktop Question -- X-Window

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Thu, 2005-12-29 at 02:45 -0600, Brandon wrote:
> Is there a remote desktop equivalent for the linux platform?  I would
> like to be able to manipulate my desktop on my linux server using
> windows over Ethernet.  Can this be done?  I know of putty and others
> for SSH but I would like to have the GUI along with the secure shell.

Sigh, I just re-explained this for someone else on the CentOS list.  ;->


- Native Display Widgets for Multiuser GUI Access

First off, 20 year-old UNIX with X-Window is _inherently_ capable of not
only being the equivalent of a "full screen remote desktop" like Windows
Terminal Server / Remote Desktop / Remote Administration (commonly via
the Citrix-crippled Remote Desktop Protocol, RDP), but also a "seemless
window" Citrix MetaFrame Server where remote windows appear on your
local desktop as if local (commonly via the full Citrix Independent
Client Architecture, ICA, protocol).

In fact, the _latter_ ("seemless windows") is the default operation of X
itself.  You launch any X application, and it connects to the designated
X-Server.  By default, when you login to the local XDM (X Display
Manager), your X-Server is the local :0.0 display.  It doesn't matter is
applications are running local or remote, _both_ "target" your local
display/input as they are set to display on your local X-Server.

The _former_ ("full desktop") is done via XDMCP.  You launch your X-
Server to connect to a remote system with an XDMCP service (the system
doesn't even need to have a display ;-).  Your desktop then runs on that
remote system, while it displays locally (and takes your local input).

All you need is a local X-Server to display remote X applications.
Virtually every UNIX platform comes with X.  For Windows, consider
Cygwin/X:  http://x.cygwin.com/  *1*


- Simultaneous GUI Access

Now simultaneous GUI access gets tricky with X.  There are some new
features to X11R7 to address this, but it hasn't been addressed very
well at the X widget/display level yet.  Using Xnest -- the nested X-
Server -- this can be done (I've never done it personally).

After Microsoft incorporated Citrix MultiWin (Graphical Display
Interface, GDI, virtualization -- long story, _all_ Windows applications
assume there is a single, physical GDI and bind to it) starting with NT
5.0 (Windows 2000), that gave Microsoft an avenue to allowed any
MultiWin client (be it RDP or ICA) to be able to view the local GDI,
virtually.  This is now known as the "Remote Administration" mode of
MultiWin -- aka Terminal Services (using RDP).  Of course, there are
limitations (especially performance).

Which brings me to the next concept ...


- Remote Framebuffer (RFB)

If you've used pcAnywhere, you've used remote framebuffer.  Instead of
sending the "raw" widgets of the GUI framework, the individual pixels
are sent.  This has the great advantage of being simple and working with
anything that renders in raw pixels.  It also has the massive
disadvantage of being very slow and fat.

Virtual Network Computing (VNC) is basically a multiplatform
implementation that has clients and servers for everything.  Under
Windows, you can run 1 server and have multiple clients connect.  NOTE:
VNC does _not_ tap into NT5.0+ (2000+) integrated MultiWin, so you
can_not_ use VNC to make yourself a "cheap" Windows Terminal Server.

On UNIX, it's a bit more tricky.

While the Xvnc service is basically a virtualized X server that creates
multiple X sessions without the need for forking off another XDM/XDMCP,
and can have multiple clients connect (including from Windows), they are
not integrated with your physical display :0.0.  You used to have to
rebuild your root X-Server with VNC support to enable this.

Fortunately, new GNOME and KDE Display Managers (GDM/KDM) now have VNC
support built-in for the physical display :0.0.  So you can share the
physical display :0.0 with their associated programs/tools.


-- Bryan

*1*  Probably the greatest advantage of X11 versus RDP/ICA is 3D.
OpenGL was designed with X11 in mind, hence OpenGL over X11 (GLX).  You
can have a cluster of applications rendering GLX widgets, then pump them
to a single (or even multiple) X-Servers with a hardware accelerated GLX
driver.

DirectX, by its very nature (which started as "Direct DOS Memory Map")
is completely designed to reliant on local hardware.  Although there is
some software back-fill, DirectX continues to be used as a wrapper to
leading-edge vendor APIs -- and not standardization for all vendors.
It's quite ironic since even the multi-vendor Architectural Review Board
(ARB) for OpenGL does a heck of a lot better job for standardizing
leading-edge APIs than the single vendor Microsoft DirectX does for
Direct3D (something that 3DLabs regularly pointed out).  But I won't
open that hole.

Just understand that the base of OpenGL (including geometry setup and
T&L from virtually day 1) versus DirectX (how do we access 20-bit DOS
memory maps from 386Enhanced mode) and the lack of anything equivalent
to GLX in the DirectX world is why OpenGL is still the mainstay API of
professional applications -- even on Windows.  Most people don't realize
that Microsoft was 100% OpenGL -- until it ran like crap under the
386Enhanced mode of Chicago (yes, Windows 98/98/Me is still 100%
386Enhanced mode), resulting in the WinG, DirectDOS MM and, eventually,
Direct2D, etc... into DirectX.

Windows 95/98/Me was _always_ slower than _all_ versions of Windows NT
at OpenGL, even after the Installable Client Drivers (ICDs) stablized
and matured for Windows 9x/Me by circa 1999-2000.


-- 
Bryan J. Smith   mailto:b.j.smith@ieee.org
http://thebs413.blogspot.com
------------------------------------------
Some things (or athletes) money can't buy.
For everything else there's "ManningCard."



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.