On 12/13/13 7:16 PM, Ronald F. Guilmette wrote: > Who are you asking? Me? I've moved on already, so don't do anything just > on my acount. > > Also, I guess I'm confused about something. One of the reasons... actually > the main reason why I stareted my experimenting with TigerVNC in particular, > out of all of the myriad different flavors of VNC that are, apparently, > available, is that I saw someplace that RedHat was behind this project, > or at least was involved. So I thought to myself "Good! That is a big > enough company that they will probably care if it doesn't work right." > > But based on your posting, I am gathering that I may have made a few too > many assumptions (about the possibility that TigerVNC might be a heavily > supported project).
Red Hat was one of the founding members of the project. They had a representative (Adam) who contributed a lot to TigerVNC in the early days, then (in 2012, IIRC) he announced that he wasn't going to be working on TigerVNC anymore. Supposedly, someone else at Red Hat took over the job of maintaining TigerVNC for use in Fedora and Red Hat Enterprise, but that person has not (to my knowledge) ever introduced themselves to the TigerVNC developers or contributed any code. Thus, I think it's fair to say that Red Hat is no longer actively involved in the development of TigerVNC. Red Hat's primary goal was always to replace the old (and no longer supported) RealVNC Free Edition code that was the basis of the VNC server in Fedora and RHEL. They weren't interested in doing anything too advanced with it, and in fact, they never did adopt TigerVNC 1.2 at all. Because TigerVNC 1.2+ relies on a custom version of FLTK, there were technical and political hurdles to getting it into Fedora, so Red Hat stuck with 1.1.0 for a while. Only recently has Fedora moved to the 1.3 branch of TigerVNC-- Fedora 18 and 19 used an alpha version, and TigerVNC 1.3.0 is now available in Rawhide (which will become Fedora 20.) Supporting these newer versions of TigerVNC necessitated building a special FLTK package for Fedora that contains the TigerVNC patches. The VirtualGL Project (which I run) was also one of the founding members of TigerVNC, but I no longer actively participate in development, although I do still monitor the mailing lists. My goal was initially to use TigerVNC as a next-gen replacement for TurboVNC, but ultimately it proved easier, both technically and politically, to just move TurboVNC forward instead. There has been some cross-pollination between the projects, though. Most notably, TigerVNC inherited many of TurboVNC's performance enhancements, and TurboVNC inherited TigerVNC's flow control extensions and its Java viewer. Cendio AB (makers of the ThinLinc remote desktop product) were the third founding member, and they are still actively developing TigerVNC. Because ThinLinc does not have a windows server, Cendio's focus is on the Unix/Linux server and on the FLTK viewer, and they have contributed almost all of the changes to those code bases since TigerVNC 1.2. Both Cendio and The VirtualGL Project support Windows apps by running a virtual machine on a Linux server, and thus it's hard for either one of us to make a solid business case for investing in WinVNC. Brian Hinz is the other primary developer these days, focused mainly on the Java viewer, but he also took over from me the job of releasing all of the TigerVNC project binaries. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
