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 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
