Any amount helps. Donations are added to the General Fund, which is used to fund maintenance and bug fixes and minor feature requests and build system enhancements and other things that aren't specifically paid for by a customer. The General Fund receives a large deposit every April, courtesy of Santos, but it is almost always exhausted by December or January.
On 3/18/17 7:37 PM, Steve Volumetric wrote: > welp, thousands I don't got....but ive been using your software long > enough that I'd be happy to make a donation. your software is the > cornerstone of how i do 3d modeling work, and i couldn't do it like this > had it not been for virtualgl and turbovnc. maybe someday i can offer more? > > On Mar 18, 2017 7:39 PM, "DRC" <[email protected] > <mailto:[email protected]>> wrote: > > Depends on the feature, but a major feature will typically cost > thousands of dollars in labor to implement. I can provide more specific > estimates offline based on specific feature requests. > > On 3/18/17 4:56 PM, Steve Volumetric wrote: > > Thank you for your thoughtful response. On security, I see where you're > > coming from in the linux-realm, I can't speak to Windows or OS X as I've > > nearly entirely cut them out of my life. > > If the cookie crumbles in the way you describe regarding security and > > java applications, then my biggest nit-pick is having fewer packages > > installed and overall having fewer inodes junking up a filesystem. > > Ideally, It'd be nice to compile the vncviewer as a static binary, but > > that's clearly not super practical at the moment, it'd just be a "nice > > to have." The fewer dependencies I need to have on a given system, the > > happier I am when it comes to backups, updates and overall management. > > Falling squarely into the category of "things that are my problem" is > > that my linux distro is little more than the kernel, a basic package > > manager which compiles things from source...or compiling things from > > source yourself so java isn't exactly at arm's length to me, but it's > > ok, I can always find a way to make it work. Luckily in this case, you > > managed to find a way to really optimize the hell out of it, and even > > over wifi raw lossless vnc-ing is incredibly responsive. When it comes > > to funding to make something possible, how much funding is that, > generally? > > > > On Sat, Mar 18, 2017 at 4:13 PM, DRC <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > Also, with respect to Java, if you are running a standalone Java > > application, then it is no more or less secure than a standalone > native > > application. The security risks you refer to are primarily related > to > > running Java in a web browser, which most web browsers don't support > > anymore. The Java TurboVNC Viewer still supports an in-browser > applet > > mode, but even the company who paid for that feature can no longer > use > > it because of lack of Java plugin support in modern browsers. It > really > > isn't an issue unless someone absolutely needs a VNC viewer that > runs in > > their browser window. Otherwise, Java Web Start can easily be used > to > > launch the TurboVNC Viewer in a "zero-install" capacity, without > > requiring any browser plugins, as long as a JVM is installed on the > > client machine. I'm also looking into extending noVNC to support > the > > RFB flow control extensions and other features necessary to make it > > perform reasonably on WAN connections. It will never perform very > well > > on LAN connections, but I'd like to at least make it as fast as > > possible, so it can serve as a stopgap for those who previously > needed > > the in-browser TurboVNC Viewer applet. The long-term solution for > an > > in-browser VNC viewer is probably WebAssembly, but all of that > stuff is > > still in a state of flux right now. > > > > With the exception of risks introduced by improper installation or > > configuration, probably the worst-case security risk of a VNC > viewer is > > that you're using the built-in session encryption feature (VeNCrypt) > > with a buggy underlying SSL implementation, which could conceivably > (but > > not easily) expose you to such exploits as a "man in the middle" > attack. > > It is conceivable that such an attack might allow the attacked to > snoop > > your Unix login credentials, if you were authenticating with the > server > > using those credentials. That's actually an argument in favor of > Java, > > however, because the underlying SSL implementation that our Java > viewer > > uses is part of the JVM, and Oracle does a pretty good job of > keeping > > abreast of any security flaws in it. Producing a cross-platform > native > > viewer would require that we either link statically with OpenSSL or > > GnuTLS (requiring us to keep abreast of any potential security > flaws in > > those libraries ourselves-- no thanks) or to load OpenSSL on demand > like > > we do in the server. The latter approach will probably be the > approach > > I take to implement session encryption in the next-gen > cross-platform > > native viewer, but that approach is really no more or less secure > than > > Java. It still relies on someone else-- in this case, the O/S > > distributor-- to keep abreast of security bugs in the SSL/TLS > libraries. > > On Linux, this is really no different than using Java, since the > > distribution-supplied OpenJDK implementations will themselves link > > against the system-supplied build of GnuTLS or OpenSSL. But Java > has a > > slight edge, because-- at least on Linux-- you can obtain it from > > multiple sources. So if the distribution-supplied JVM has a > security > > bug that Oracle has fixed, you can install Oracle's version until > the > > distribution maintainers fix the bug in their implementation. > > > > The historical reasons behind the hybrid Java/native viewer on Mac > and > > Linux platforms were primarily monetary. I received funding in the > 2012 > > timeframe to develop a proof-of-concept Android TurboVNC Viewer, and > > since Android is a Java-based platform, the first phase of this > involved > > improving the Java TurboVNC Viewer so that it had the necessary > > underlying features to provide a full-fledged TurboVNC Viewer > > experience. Phase 2 would have involved developing a new, > > Android-specific GUI. The project was dropped prior to Phase 2, but > > since the resulting Java TurboVNC Viewer was much more > user-friendly and > > feature-rich than the existing Un*x/X11 viewer (which, at the time, > was > > based on Xt, which required XQuartz on Mac and had the crappiest GUI > > imaginable), the Java viewer was phased in as a replacement. In > > TurboVNC 1.2, the Java viewer fully replaced the Xt viewer on Mac > > platforms and was provided as an option on Linux platforms. With > > TurboVNC 2.0, I introduced a new glueware library on Linux that > worked > > around some underlying Java/X11 interaction issues, which allowed > the > > Java/native hybrid viewer to fully replace the Xt viewer, so the Xt > > viewer was retired in that release. > > > > I do recognize that, at least on Mac and Windows platforms, a Java > > viewer introduces additional install dependencies that may not be > > desirable in all cases. Also, our Windows viewer is popular and has > > some GUI features that the Java viewer lacks-- another reason to > expand > > it to other platforms. Fortunately, there is now funding to look > into > > this, although the feature may not be fully implemented until next > year > > because it is not the highest priority. > > > > > > On 3/17/17 9:37 PM, Steve Volumetric wrote: > > > DRC - thanks for putting all this together, by the way. I'm a > big fan. > > > Unrelated, I gave up on trying to compile the turbovnc viewer > from > > > source (my linux distro is too weird) and I got up and running > off your > > > precompiled rpm that I pried apart. You're right - the > performance is a > > > staggering improvement over TigerVNC even with the java > dependency! > > > > > > On Fri, Mar 17, 2017 at 9:34 PM, DRC > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > > > > > The Windows viewer has a pure C++ version, but other > platforms require > > > Java at the moment. Why is that a limitation? It's as fast > as our > > > native viewer and considerably faster than TigerVNC's native > viewer on > > > Mac platforms. I am looking at a cross-platform native > viewer in the > > > long term, probably based on our Windows code but ported to > some > > > cross-platform toolkit like GTK. For now, however, Mac and > Linux > > > require Java. > > > > > > On 3/17/17 6:22 PM, Steve Volumetric wrote: > > > > I'm hoping the viewer isn't completely java dependent, > though so far > > > > that's the only way I've been able to build it. > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > TurboVNC-Users mailing list > > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users> > > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users>> > > > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > TurboVNC-Users mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > <https://lists.sourceforge.net/lists/listinfo/turbovnc-users> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
