:: Re: [DNG] X forwarding over SSH ove…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] X forwarding over SSH over ADSL
Brad Campbell <lists2009@???> writes:
> On 13/03/16 00:48, Rainer Weikusat wrote:
>> Brad Campbell <lists2009@???> writes:
>>> On 08/03/16 04:41, Simon Hobson wrote:
>>>>
>>>> VNC is lousy over anything but a very fast link, it's just a remote
>>>> framebuffer - anything painted to the screen is bit copied to the
>>>> client which is bandwidth intensive.
>>>
>>> Whereas tightvnc works quite well over almost anything, and if you are
>>> willing to drop to a small colour pallete
>>
>> Considering that tightvnc is Windows-only software it seems a bit out of
>
> Que? Better not tell any of my linux boxes that have been using it as
> both a server and client for many more years than I care to remember.


There's a web site,

http://www.tightvnc.com

which quite plainly states that

    Requirements
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    For building, Windows Software Development Kit (SDK) for Windows 8
    is required.


    Building
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    Two versions of the MS Visual Studio are supported. Choose the one
    of these files in the TightVNC distribution root folder and compile
    the source code.


      * MS Visual C++ 2010 (tightvnc2010.sln)
      * MS Visual C++ 2008 (tightvnc.sln)


http://www.tightvnc.com/doc/win32/building.txt

Further,

    TightVNC 2.0 is available for Windows only. It does not include
    components for Unix/Linux yet.


http://www.tightvnc.com/release-2.0.php

As this statement was released in 2010, referring to "tightvnc" as
'windows-only software' seems appropriate. As one can also gather from
the site, development of anyhing non-windows was halted ca 2009,

http://www.tightvnc.com/release-1.3.10.html

[...]

> I've snipped the remainder of your un-informed rant.


This claims VNC compatibility due to using the same 'remote framebuffer'
protocol. This means it suffers from the exact same problem of sending
bitmap graphics rendered on some remote machine to a dumb 'display
device'.