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]> 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]>> 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].
net
> <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]>
> 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
------------------------------------------------------------------------------
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
