TightVNC feature has been renamed to TigerVNC

[Daniel P. Berrange]

On Wed, Mar 04, 2009 at 03:36:04AM -0500, Adam Tkac wrote:
> Hi all,
> 
> 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.
> 
> 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 -
> https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LFD.2.00.0902271116020.25749%40maggie.lkpg.cendio.se.
> 
> 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.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|