On Wed, Mar 04, 2009 at 03:36:04AM -0500, Adam Tkac wrote:
it was some concern why TightVNC feature has been renamed to TigerVNC
one minute before beta freeze. Let me try explain background.
In Fedora 10 we have vnc based on RealVNC source but upstream doesn't
put any effort to accept patches which we have so I decided replace
RealVNC by TightVNC in F11.
Current TightVNC "trunk", which was supposed to be our F11 vnc, uses
same codebase as RealVNC. TightVNC adds Tight extension and some other
useful features. I joined to TightVNC upstream about one year ago and
successfully ported all Fedora changes to upstream.
Unfortunately TightVNC lead developer wasn't able to create any plan
for the next release of UN*X version. All UN*X developers asked him
what features will be in next version, when the next version will be
released etc. It was continual development without any milestones
which was unacceptable for some developers thus we created fork called
TigerVNC is new project, it exists about two weeks. All active
TightVNC UN*X developers left TightVNC and joined TigerVNC. Also lead
developer of TurboVNC (VNC which is focussed on performance, 3D gaming
etc) joined us so I think this project will have better future than
TightVNC. You can read "official" statement from upstream -
Due reasons written above I decided to switch to TigerVNC ASAP because
I think it will be better than TightVNC.
I hope I threw enough light on this topic.
Thanks for the update - it is good to see that there's now a viable
open source project for improving VNC server support on UNIX.
Do you have any plans to implement the VeNCrypt extension in the
server side ? This is the TLS/SSL + x509 certificate extension we
have standardized on for QEMU, Xen, KVM and GTK-VNC (used by
virt-viewer, virt-manager and vinagre clients). I would also like
to add it to the GNOME VINO, since VINO's own TLS extension is flawed
by not using x509 credentials. That leaves TigerVNC without a good
interoperable TLS extension, so it'd be desriable to implement VeNCrypt
there so we have a consistent TLS extension that's interoperable
across all the VNC clients & servers in Fedora.
Following on from that I also recently defined & implemented another
VNC auth extension based on SASL. This provides for a good extendable
authentication capability, most importantly including GSSAPI Kerberos
for single sign on. I've got it implemented for QEMU, KVM, GTK-VNC and
VINO already, so again it'd be good to plan for adding it to TigerVNC
too so we have a widely interoperable strong authentication system.
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|