On 3/8/13 5:00 PM, Dragseth Roy Einar wrote: > Thanks to all for the quick and insightful responses. > > As goes for TurboVNC vs TigerVNC, I was under the impression that they would > merge. Is this not the case? > > I took a quick stab at using TurboVNC, but could not make it work with xinetd > as TigerVNC do. (But that probably belongs to the TurboVNC list) It might > make sense to use TurboVNC as we plan to augment this service with VirtualGL > for the users that need to use more demanding 3D applications. > > We do not intend to support persistent sessions (at least in the first > incarnation) so sessions terminate as soon as a client disconnect.
Please report the xinetd bug in the bug tracker under the VirtualGL project on SourceForge or on virtualgl-us...@lists.sourceforge.net, and I will look into it. The plan to merge the solutions fell through in late 2011/early 2012 due to differing project goals and focuses. TigerVNC is much more "in its element" as a vendor-supplied solution that is tied to a specific X server code base. The advantage of that approach is that X server issues become the domain of the integrator (such as Red Hat) and not something that the VNC project has to worry much about. The disadvantage is that the build procedure is complicated and generally different on every platform. TurboVNC has always maintained its own in-tree X server code base. The advantage to that is having a self-contained build that's easily reproducible, but the disadvantage is that we have to fix X server bugs ourselves if they arise. For instance, we've had to back-port some of the more modern X extensions, such as RENDER and RANDR, to allow "modern" window managers to work properly. With TigerVNC, on the other hand, if the WM works properly on the "local" X server, it should work properly in TigerVNC, assuming that TigerVNC is built from the machine's X server code base. When I was working actively on The TigerVNC Project, we had a series of scripts that generated a "cross-compatible" build using a "known good" X server code base. The scripts are still there (unix/build-xorg) and still work, but no one is using them actively to produce builds, AFAIK. The issue with this approach from a project point of view was that, if an X server problem arose (which many did), we had to upgrade the entire X.org infrastructure used in the cross-compatible build, and this often created additional compatibility issues with the build chain or even sometimes additional X issues that didn't exist under the older X.org code base. Also, the cross-compatible build just took forever, because it had to build all of X.org and its dependencies from source. It was a completely impossible situation to debug X server issues in that environment. More generally, it's the case that pretty much everyone involved in TigerVNC has their own "special sauce" for building it. I was using unix/build-xorg, Cendio uses their own very customized environment (so it was often the case that something they would do would break my build or vice versa), and Red Hat builds against the system-supplied X server code base in Fedora and RHEL. Thus, I was pretty much on my own for maintaining the cross-compatible build process, and it required a lot of pro bono hours on my part to keep it running smoothly. Ultimately, the performance focus also became a sticking point. TurboVNC has always been about maximum 3D/video performance. The idea is that those apps are performance-critical, and a drop in frame rate for an interactive 3D app is going to be noticed a lot more quickly than a drop in frame rate for Firefox or OpenOffice. Thus, we spent many hundreds of hours designing encoding methods for TurboVNC that maximize the performance for 3D and video workloads. Those encoding methods were ported into TigerVNC as well. However, because TigerVNC is trying to be a general-purpose solution, it would often be the case that something would be checked in that improved 2D performance but killed 3D performance, and I'd have to fight to get it back. After a few debates on this, the suggestion arose that I maintain my own version of TigerVNC focused on 3D performance, and at that point, it became apparent that there was no real advantage to that vs. moving TurboVNC forward. Additionally, it would have been a lot of work to bring in the TurboVNC-specific features, like the auth extensions and Automatic Lossless Refresh and multi-threaded encoding, etc., and I was getting push-back on a lot of those as well. The solutions were and are just too different. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
