OpenJDK
18 views
Skip to first unread message
Rafael Guimaraes
Mar 24, 2021, 10:57:47 AM3/24/21
to turbovn...@googlegroups.com
Hi DRC,
Have you ever faced any kind of problems when using TurboVNC+VirtualGL through the Java Client running on Windows with OpenJDK 11+IcedTeaWeb? We are planning to abandon Oracle JRE due to licensing issues and I would like to know if you (or someone else) have good or bad experiences with OpenJDK+IcedTeaWeb...
Thanks in advance.
Cheers,
Rafael
DRC
Mar 24, 2021, 11:01:40 AM3/24/21
to turbovn...@googlegroups.com
No problems of which I'm aware. OpenJDK is the default Java
implementation on Linux, so basically all Linux TurboVNC users have been
using OpenJDK for years. The evolving TurboVNC 3.0 Viewer embeds a
stripped-down version of OpenJDK 11 so it can work without a
pre-installed JRE.
implementation on Linux, so basically all Linux TurboVNC users have been
using OpenJDK for years. The evolving TurboVNC 3.0 Viewer embeds a
stripped-down version of OpenJDK 11 so it can work without a
pre-installed JRE.
Rafael Guimaraes
Mar 24, 2021, 11:08:02 AM3/24/21
to turbovn...@googlegroups.com
How will TurboVNC 3.0 work exactly without JRE? How will users be able to launch the client when accessing a session through a web portal, for example?
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org.
DRC
Mar 24, 2021, 1:37:34 PM3/24/21
to turbovn...@googlegroups.com
That depends on how the web portal is designed. TurboVNC web portals
tend to do one of two things:
1. The portal generates a .vnc connection information file for a
particular TurboVNC session and downloads the file to the client's web
browser, which passes that file to the standalone TurboVNC Viewer
installed on the client. Typically the .vnc file contains a one-time
password, generated by the portal for the TurboVNC session, so the
standalone TurboVNC Viewer can connect to and authenticate with the
TurboVNC session automatically.
This mode of operation currently works with all of the TurboVNC 2.2.x
Viewer flavors (Windows native, Windows/Java, Un*x, Mac) and will
continue to work the same way with the unified TurboVNC 3.0 Viewer. The
only difference is that you won't need a separate JRE in order to use
the Java/Mac/Un*x TurboVNC Viewer.
2. The portal generates a .jnlp (Java Network Launching Protocol) file
for a particular TurboVNC session and downloads the file to the client's
web browser, which passes that file to a JRE that has Java Web Start
capabilities. JWS then downloads the Java TurboVNC Viewer JAR files
from the portal's web server and launches the Java TurboVNC Viewer,
connecting to and authenticating with the TurboVNC session automatically
as in (1) above.
Java Web Start is obsolete, from Oracle's point of view. Your only
options for continuing to use it in a production environment are Java SE
8 and OpenJDK 8 + IcedTea-Web (ITW.) (OpenWebStart may also be an
option, but they don't appear to have enterprise support, and I don't
know anything about the quality of that solution.) Java SE 8 ended
public updates for commercial users in January of 2019, and Premier
Support for it will end in March of 2022, so the enterprise support
options for JWS are quickly disappearing. (OpenJDK 8 will probably stop
being updated in that same timeframe.)
Thus, in TurboVNC 3.0, I've shifted the focus away from JWS and instead
developed the TurboVNC Session Manager, which provides a standalone
alternative to a web portal that will be suitable for most casual use
cases. Web portals that generate .vnc connection info files will
continue to be fully supported. Web portals that use JWS will be
supported only in a paid support capacity, and the TurboVNC 3.0 Server
no longer documents or facilitates that deployment method.
(Specifically, the TurboVNC 3.0 Server no longer provides signed JARs or
an embedded web server, so enterprises that wish to use the TurboVNC 3.0
Viewer with JWS will have to package the TurboVNC Helper libraries for
Un*x, Windows, and Mac into separate JARs, sign those TurboVNC Helper
JARs as well as the Java TurboVNC Viewer JAR, and deploy the JARs using
a standalone web server and a dedicated web portal.)
The general mode of thinking here is:
- JWS isn't a "zero-install" deployment solution unless a JWS-equipped
JRE is universally available, and that is less the case these days than
it used to be. Generally speaking, only large enterprises can ensure
that a JRE is universally available on their client machines. From
TurboVNC's perspective, I can't rely on a JRE to be available.
- If a JRE isn't universally available, then it's a lot easier to
install a standalone TurboVNC Viewer than it is to install a JRE + the
Java TurboVNC Viewer.
- Thus, at least some of the session management functionality that was
previously implemented using JWS and web portals is being implemented
more directly in the standalone TurboVNC 3.0 Viewer, via the TurboVNC
Session Manager.
Also, it's worth noting that the Java TurboVNC Viewer relies
increasingly on native code in order to work around certain JRE
limitations. Specifically, native code is required for:
- High-speed JPEG decoding (all platforms)
This could previously be implemented with JWS by using the JNI JAR
files from libjpeg-turbo 1.2.x-2.0.x. With TurboVNC 3.0, however, the
high-speed JPEG decoder has been moved into the TurboVNC Helper library.
- Transmitting Alt-Tab and other special keystrokes to the server
(Windows, Un*x)
- Extended input device/drawing tablet support (all platforms)
- Multi-screen spanning (Un*x)
- Password-less SSH authentication (all platforms)
This is a new feature in TurboVNC 3.0.
If you're using JWS, then the embedded JRE in the TurboVNC 3.0 Viewer
isn't relevant to your use case, since you aren't using the standalone
TurboVNC Viewer to begin with. Nothing would prevent you from
continuing to use the Java TurboVNC 2.2.x Viewer with JWS. Just
understand that the support for JWS will become increasingly spotty as
time goes on. The first web portal that was ever designed around
TurboVNC uses .vnc connection info files, and that remains the best
approach.
DRC
On 3/24/21 10:07 AM, Rafael Guimaraes wrote:
> How will TurboVNC 3.0 work exactly without JRE? How will users be able
> to launch the client when accessing a session through a web portal, for
> example?
>
> Em qua., 24 de mar. de 2021 às 12:01, DRC <d...@virtualgl.org
> <mailto:d...@virtualgl.org>> escreveu:
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
tend to do one of two things:
1. The portal generates a .vnc connection information file for a
particular TurboVNC session and downloads the file to the client's web
browser, which passes that file to the standalone TurboVNC Viewer
installed on the client. Typically the .vnc file contains a one-time
password, generated by the portal for the TurboVNC session, so the
standalone TurboVNC Viewer can connect to and authenticate with the
TurboVNC session automatically.
This mode of operation currently works with all of the TurboVNC 2.2.x
Viewer flavors (Windows native, Windows/Java, Un*x, Mac) and will
continue to work the same way with the unified TurboVNC 3.0 Viewer. The
only difference is that you won't need a separate JRE in order to use
the Java/Mac/Un*x TurboVNC Viewer.
2. The portal generates a .jnlp (Java Network Launching Protocol) file
for a particular TurboVNC session and downloads the file to the client's
web browser, which passes that file to a JRE that has Java Web Start
capabilities. JWS then downloads the Java TurboVNC Viewer JAR files
from the portal's web server and launches the Java TurboVNC Viewer,
connecting to and authenticating with the TurboVNC session automatically
as in (1) above.
Java Web Start is obsolete, from Oracle's point of view. Your only
options for continuing to use it in a production environment are Java SE
8 and OpenJDK 8 + IcedTea-Web (ITW.) (OpenWebStart may also be an
option, but they don't appear to have enterprise support, and I don't
know anything about the quality of that solution.) Java SE 8 ended
public updates for commercial users in January of 2019, and Premier
Support for it will end in March of 2022, so the enterprise support
options for JWS are quickly disappearing. (OpenJDK 8 will probably stop
being updated in that same timeframe.)
Thus, in TurboVNC 3.0, I've shifted the focus away from JWS and instead
developed the TurboVNC Session Manager, which provides a standalone
alternative to a web portal that will be suitable for most casual use
cases. Web portals that generate .vnc connection info files will
continue to be fully supported. Web portals that use JWS will be
supported only in a paid support capacity, and the TurboVNC 3.0 Server
no longer documents or facilitates that deployment method.
(Specifically, the TurboVNC 3.0 Server no longer provides signed JARs or
an embedded web server, so enterprises that wish to use the TurboVNC 3.0
Viewer with JWS will have to package the TurboVNC Helper libraries for
Un*x, Windows, and Mac into separate JARs, sign those TurboVNC Helper
JARs as well as the Java TurboVNC Viewer JAR, and deploy the JARs using
a standalone web server and a dedicated web portal.)
The general mode of thinking here is:
- JWS isn't a "zero-install" deployment solution unless a JWS-equipped
JRE is universally available, and that is less the case these days than
it used to be. Generally speaking, only large enterprises can ensure
that a JRE is universally available on their client machines. From
TurboVNC's perspective, I can't rely on a JRE to be available.
- If a JRE isn't universally available, then it's a lot easier to
install a standalone TurboVNC Viewer than it is to install a JRE + the
Java TurboVNC Viewer.
- Thus, at least some of the session management functionality that was
previously implemented using JWS and web portals is being implemented
more directly in the standalone TurboVNC 3.0 Viewer, via the TurboVNC
Session Manager.
Also, it's worth noting that the Java TurboVNC Viewer relies
increasingly on native code in order to work around certain JRE
limitations. Specifically, native code is required for:
- High-speed JPEG decoding (all platforms)
This could previously be implemented with JWS by using the JNI JAR
files from libjpeg-turbo 1.2.x-2.0.x. With TurboVNC 3.0, however, the
high-speed JPEG decoder has been moved into the TurboVNC Helper library.
- Transmitting Alt-Tab and other special keystrokes to the server
(Windows, Un*x)
- Extended input device/drawing tablet support (all platforms)
- Multi-screen spanning (Un*x)
- Password-less SSH authentication (all platforms)
This is a new feature in TurboVNC 3.0.
If you're using JWS, then the embedded JRE in the TurboVNC 3.0 Viewer
isn't relevant to your use case, since you aren't using the standalone
TurboVNC Viewer to begin with. Nothing would prevent you from
continuing to use the Java TurboVNC 2.2.x Viewer with JWS. Just
understand that the support for JWS will become increasingly spotty as
time goes on. The first web portal that was ever designed around
TurboVNC uses .vnc connection info files, and that remains the best
approach.
DRC
On 3/24/21 10:07 AM, Rafael Guimaraes wrote:
> How will TurboVNC 3.0 work exactly without JRE? How will users be able
> to launch the client when accessing a session through a web portal, for
> example?
>
> Em qua., 24 de mar. de 2021 às 12:01, DRC <d...@virtualgl.org
>
> No problems of which I'm aware. OpenJDK is the default Java
> implementation on Linux, so basically all Linux TurboVNC users have
> been
> using OpenJDK for years. The evolving TurboVNC 3.0 Viewer embeds a
> stripped-down version of OpenJDK 11 so it can work without a
> pre-installed JRE.
>
> On 3/24/21 9:57 AM, Rafael Guimaraes wrote:
> > Hi DRC,
> >
> > Have you ever faced any kind of problems when using
> TurboVNC+VirtualGL
> > through the Java Client running on Windows with OpenJDK
> 11+IcedTeaWeb?
> > We are planning to abandon Oracle JRE due to licensing issues and I
> > would like to know if you (or someone else) have good or bad
> experiences
> > with OpenJDK+IcedTeaWeb...
> >
> > Thanks in advance.
> >
> > Cheers,
> > Rafael
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-users%2Bunsu...@googlegroups.com>.
> No problems of which I'm aware. OpenJDK is the default Java
> implementation on Linux, so basically all Linux TurboVNC users have
> been
> using OpenJDK for years. The evolving TurboVNC 3.0 Viewer embeds a
> stripped-down version of OpenJDK 11 so it can work without a
> pre-installed JRE.
>
> On 3/24/21 9:57 AM, Rafael Guimaraes wrote:
> > Hi DRC,
> >
> > Have you ever faced any kind of problems when using
> TurboVNC+VirtualGL
> > through the Java Client running on Windows with OpenJDK
> 11+IcedTeaWeb?
> > We are planning to abandon Oracle JRE due to licensing issues and I
> > would like to know if you (or someone else) have good or bad
> experiences
> > with OpenJDK+IcedTeaWeb...
> >
> > Thanks in advance.
> >
> > Cheers,
> > Rafael
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-user...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org
> <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>.
> https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-user...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-user...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Rafael Guimaraes
Mar 24, 2021, 2:38:40 PM3/24/21
to turbovn...@googlegroups.com
Ok, understood!
Today I've tested OpenJDK 11 with IcedTeaWeb and it worked with our jnlp-based portal... However I think I will move to the .vnc-based solution.
The only drawback of this solution, in my case, is that in order to update TurboVNC to newer releases, I will have to update all my clients... With the jws approach I only had to update the server... Well, that's part of the game!
Thanks for the info!
Cheers,
Rafael
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org.
DRC
Mar 24, 2021, 3:54:05 PM3/24/21
to turbovn...@googlegroups.com
Yes, that is a limitation. I would be amenable to developing some sort
of in-app update mechanism for the TurboVNC Viewer, but it would have to
be a funded development project. I could also probably build a TurboVNC
Viewer package for Chocolatey or another Windows packaging environment,
but again, funded development. (Also, that would still require that
each user update the TurboVNC Viewer themselves. It would just be a bit
easier to do so.) I could also introduce a directive into the .vnc
connection info file that requires a minimum version of the TurboVNC
Viewer and prompts the user to upgrade their viewer if it is below the
minimum version, but I could see that being a tech support nightmare for
large organizations.
From a philosophical point of view, I was a fan of Java Web Start and
was sad to see it jettisoned, but unfortunately Oracle made its bed in
that regard many years earlier. Java was among several software
technologies that they acquired from Sun and tried to turn into cash
cows without paying much heed to long-term technological trends. When
Oracle refused to modernize the Java browser plugin, that led to a lot
of enterprises banning JREs over browser security concerns, since the
browser plugin was an inseparable part of the JRE. That significantly
reduced the ubiquity of the JRE, which significantly reduced the
relevance of JWS. Eventually, their only choice was to be reactive
rather than proactive-- jettisoning all of the web functionality from
the JRE and repositioning it as a runtime engine for standalone
applications (much like .NET is on Windows.) IMHO, they could've made
Java a ubiquitous language had they taken a more long view of it and
treated it as a strategic technology rather than a cash cow, but that
would have required giving it away for free-- something that Sun was a
lot more inclined to do than Oracle.
On 3/24/21 1:38 PM, Rafael Guimaraes wrote:
> Ok, understood!
>
> Today I've tested OpenJDK 11 with IcedTeaWeb and it worked with our
> jnlp-based portal... However I think I will move to the .vnc-based
> solution.
> The only drawback of this solution, in my case, is that in order to
> update TurboVNC to newer releases, I will have to update all my
> clients... With the jws approach I only had to update the server...
> Well, that's part of the game!
> Thanks for the info!
>
> Cheers,
> Rafael
>
> Em qua, 24 de mar de 2021 14:37, DRC <d...@virtualgl.org
> <mailto:d...@virtualgl.org>> escreveu:
> > <mailto:d...@virtualgl.org <mailto:d...@virtualgl.org>>> escreveu:
> > <mailto:turbovnc-users%2Bunsu...@googlegroups.com
> <mailto:turbovnc-users%252Buns...@googlegroups.com>>.
> > <mailto:turbovnc-user...@googlegroups.com
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com>
>
> >
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org>.
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4_807%2BnaH_p22sBgJRrNyRuQPGJWJUWxa_jK_YVhUioFLg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
of in-app update mechanism for the TurboVNC Viewer, but it would have to
be a funded development project. I could also probably build a TurboVNC
Viewer package for Chocolatey or another Windows packaging environment,
but again, funded development. (Also, that would still require that
each user update the TurboVNC Viewer themselves. It would just be a bit
easier to do so.) I could also introduce a directive into the .vnc
connection info file that requires a minimum version of the TurboVNC
Viewer and prompts the user to upgrade their viewer if it is below the
minimum version, but I could see that being a tech support nightmare for
large organizations.
From a philosophical point of view, I was a fan of Java Web Start and
was sad to see it jettisoned, but unfortunately Oracle made its bed in
that regard many years earlier. Java was among several software
technologies that they acquired from Sun and tried to turn into cash
cows without paying much heed to long-term technological trends. When
Oracle refused to modernize the Java browser plugin, that led to a lot
of enterprises banning JREs over browser security concerns, since the
browser plugin was an inseparable part of the JRE. That significantly
reduced the ubiquity of the JRE, which significantly reduced the
relevance of JWS. Eventually, their only choice was to be reactive
rather than proactive-- jettisoning all of the web functionality from
the JRE and repositioning it as a runtime engine for standalone
applications (much like .NET is on Windows.) IMHO, they could've made
Java a ubiquitous language had they taken a more long view of it and
treated it as a strategic technology rather than a cash cow, but that
would have required giving it away for free-- something that Sun was a
lot more inclined to do than Oracle.
On 3/24/21 1:38 PM, Rafael Guimaraes wrote:
> Ok, understood!
>
> Today I've tested OpenJDK 11 with IcedTeaWeb and it worked with our
> jnlp-based portal... However I think I will move to the .vnc-based
> solution.
> The only drawback of this solution, in my case, is that in order to
> update TurboVNC to newer releases, I will have to update all my
> clients... With the jws approach I only had to update the server...
> Well, that's part of the game!
> Thanks for the info!
>
> Cheers,
> Rafael
>
> Em qua, 24 de mar de 2021 14:37, DRC <d...@virtualgl.org
> <mailto:turbovnc-users%252Buns...@googlegroups.com>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org
> <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>
> >
> <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "TurboVNC User Discussion/Support" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-users%2Bunsu...@googlegroups.com>
> >
> https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org
> <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>
> >
> <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org <https://groups.google.com/d/msgid/turbovnc-users/928813eb-f486-9fcb-f27e-190af20f7c4e%40virtualgl.org>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "TurboVNC User Discussion/Support" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to turbovnc-user...@googlegroups.com
> > <mailto:turbovnc-user...@googlegroups.com
> <mailto:turbovnc-users%2Bunsu...@googlegroups.com>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com
> > To view this discussion on the web visit
> >
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com>
>
> >
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4__x07tCn8-AFyPJTjKeTObSXjBWhB1avU5K22fyjpX%2B8A%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-users%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org
> <mailto:turbovnc-users%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/turbovnc-users/6fc02165-379f-c88f-71c1-dfef61767773%40virtualgl.org>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/turbovnc-users/CAMCG4_807%2BnaH_p22sBgJRrNyRuQPGJWJUWxa_jK_YVhUioFLg%40mail.gmail.com
> --
> You received this message because you are subscribed to the Google
> Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to turbovnc-user...@googlegroups.com
> <mailto:turbovnc-user...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/turbovnc-users/CAMCG4_807%2BnaH_p22sBgJRrNyRuQPGJWJUWxa_jK_YVhUioFLg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages