Slashdot Mirror
VNC, No Longer Orphaned
geogeek6_7 writes "Icronic informs us of a couple new developments to everyone's favorite piece of remote-managment software, VNC. You may remember that the UK Lab responsible for the creation and maintainence of VNC closed. A company called RealVNC has been formed, sporting the original coders from the AT&T lab, and aiming to 'act as the focal point for open source VNC.' Secondly, the new company has released version 3.3.4 of VNC for Windows and Linux. Greater security and a new, speed-enhancing auto-encoding feature are included among many others in the new version."
I'd have to agree that VNC isn't exactly good on dialup connections or even ISDN.
However, this is what tightvnc is for. Regular VNC works very well in a LAN though, and works quite well from every broadband connection I've used.
But this VNC solution is really solid in a mixed Windows, Novell, and MAC OS X enviornment.
There's a version of VNC for Mac OS 9 as well.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
there is the disk sharing and audio piping in RDC5 as well..
-- Who is the bigger fool? The fool or the fool who follows him? --
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
some tips: generally you are better off NOT enabling ssh compression as VNC's compression works better. Supposedly tightVNC is the best for narrow pipes. But on fat pipes in actually is better not to compress. if you are worried about security do two things. first always turn off the http port (on by default at 580x). Second, for extra security only allow connections to/from loopback 127.0.0.1. Then use ssh to send it where you want. Finally, note that VNC itself is not encoded so the ONLY protection you are getting is the SSH encoding. If you dont tunnel all the way you are exposed. However since it is graphics info and not plain ascii, it takes a clever hacker to actually decode what you are sending in the clear.
Some drink at the fountain of knowledge. Others just gargle.
The current maintainer for OSXVNC has a web page here.
The dogcow says "Moof!"
I use the client and server on win2k boxes, and the new version is noticeably faster. I definitely recommend an upgrade for anyone using the older version on windows.
It is quite possible from a windows box, I use WinXP quite often and half of my work is done through a secure connection to my Linux boxes.
Putty is a great windows ssh client that is free to boot. It supports compression and port forwarding ( relaying too).
When configuring a new connection under putty, check the 'Connection->SSH-Tunnels' panel and check X11 forwarding, and add a local forwarding of say 5903 and destination as something like networkbox:5903. Then click Add and it will display like 'L5903 networkbox:5903'. Rember to save the session with a name and you will be set.
Rember though that the ip or system name will be relative to the box you have the ssh connection into. Packets will arive at the end of the tunnel and then be routed to the destination machine and port specified. In the above example, once connected to the remote machine, you will then be able to fire up vncviewer and connect to localhost:3 and have your connection attempt forwarded through the tunnel and on to the destination machine. Of course you will need to have vnc running as session 3 for this example to work without modification. Good luck.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
If you use VNC, they are accepting donations at http://www.realvnc.com/contribute.html.
x0rfbserver. Run it in your main X session and it will make it remotely accessible by other RFB clients (such as xrfbviewer and vncclient). Oh, and you want version >= 0.6.1 (google for rfb-0.6.1.tar.gz if necessary)
.
RDP and X11 will always be faster than VNC, simply because they do not send bitmaps. They transmit API calls, which are much smaller, but come at the price of being tied to an architecture/subset of the functionality.
VNC on the other hand does not care -- it will send everything as a bitmap, compressed of course.
So RDP/X11 will be faster, but you will not be able to administer cross platform, unless either linux gets an RDP client, or windows runs X11 architecture for everything.
badness 10000
Unless i am mightily mistaken: in a word, no. VNC is released under the terms of the GPL. This means that unless this new company owns ALL of the copyright to ALL of the code in VNC, which would mean they could relicense it-- which seems unlikely-- either an Aladdin-style or MysqlAB-style profit model is kind of out of the question.
If they link against GPLed code that they do not own the copyright to, and they distribute the result, they must put the resulting product under the GPL, it must be free as in speech, and the people they sell it to can redistribute it freely.
Correct me if i am wrong.
It does not matter if it implements or not Win32 API.
The API that he is referring to is the RDP API or protocol.
Rdesktop implements the RDP API and renders the screen. See rdesktop info on the protocol.
However being that the RDP protocol is apparently not documented (propietary?), it is easier for VNC to transfer the screen and have their own protocol.
When you say "So RDP must be bitmap-based", it is almost like saying that when using a web browser, you get screen shots, knowing the protocol, the client implements the rendering of the pages or screens.
Cheers.
There are a couple of things that you should be aware of before putting VNC on Windows 2000 servers. The first is the well-known problems with security, including the "encrypted" hash stored in the registry and the brute force vulnerability.
More importantly, though, for those of you thinking of running VNC on heavily-used Windows servers is that the CPU run queue tends to increase by 8 or so when VNC is in full screen polling mode. If you want to run perfmon over a remote connection, the two free RDP connections on W2K Server are a much better choice.
This may be odd to you, but my fortune 500 company would much rather pay for software that comes with a service contract than use free software.
As an example, we don't have a mailing list type technology installed. We began to investigate L-Soft
(Who by the way don't want you to say "listserv" unless you're referring to their brand of mailing list technology - I'm sure that kleenex and xerox felt the same way. But I digress...)
We decided not to implement anything because we couldn't afford to pay for the software licenses. Never mind that we need that technology, and that the ROI for building it is huge....
I proposed that we use free software to solve that problem. The answer was no.
The company position was:
a) we want someone to help us if it breaks,
b) we want someone to sue if it breaks something really important, and
c) if the software is free, how can we recover our costs? Our internal customers will know that we paid nothing, and won't want to reimburse us for the engineering costs.
None of these reasons may make sense to you, but they are a cultural perspective that makes perfect sense to folks who run billion-dollar companies.
There are LOTS of companies that will be glad to pay for support of a free product. Just ask Eric Allman! http://www.sendmail.org/~eric/
But Herr Heisenberg, how does the electron know when I'm looking?