Provide a way for vglclient to automatically startup on MacOS at login ?
Scott
DRC
I can appreciate the pain of signing and notarizing macOS packages. It took me probably a week of unpaid labor to figure that out. I don't agree with that requirement and feel that it is toxic to open source development, but it is what it is.
Regardless, our official packages are not
a mechanism for deploying downstream customizations. I'm the
one who has to field support requests regarding the software I
release, so when I release something, I need to be able to stand
behind it. I can't do that unless I have thoroughly tested and
documented it. That takes time, and time is money. Unless
someone is specifically paying me for a project, I have to use
the VirtualGL General Fund to implement it. In order to use the
General Fund for something, it needs to be broadly beneficial to
the community at large.
Your solution would be difficult or impossible to support in the general case, because vglclient requires XQuartz, and there is no guarantee that XQuartz will be launched at login. vglclient is designed to be launched by the vglconnect script. That is the supported and documented use case.
Furthermore, vglclient is considered a legacy solution at this point, so I'm not interested in extending it. The bulk of the development effort in The VirtualGL Project has been focused on TurboVNC in recent years. TurboVNC has built-in SSH-based session management, so it is a much more seamless solution than vglclient.
DRC
Scott
>
> Furthermore, vglclient is considered a legacy solution at this point, so I'm not interested in extending it. The bulk of the development effort in The VirtualGL Project has been focused on TurboVNC in recent years.
Thanks Again,
DRC
> Ok… thanks for your response. I think this is unfortunate because many of our users (in-house) do not want to use a VNC. They are Mac or Windows users and just need to run a few specific Linux applications from their computers using various methods. A VNC imposes the use of a Linux desktop. Long term, we need to move away from X11/OpenGL and VirtualGL is a very good solution until we can do that. We will probably move to Wayland/Waypipe without a VNC.
since 2009, so I have to restrict the scope to that which I can support
as an individual developer with 10-15 hours of funded labor per month.
Anything outside of that scope requires more specific project funding,
and even then, the solution has to be something that I can continue to
support after the funding is gone.
The earliest versions of VirtualGL (prior to 2.1) actually did run
vglclient as a daemon that marshaled VGL Transport protocol requests to
all X servers running on a particular client. However, that was
problematic for various reasons, not the least of which was that
vglclient couldn't detect the presence or capabilities of an X server
until it received a request through the VGL Transport to connect to the
X server. That made failures hard to diagnose. There were also issues
related to X authentication. (If I recall, SSH X11 tunneling was
problematic with that solution.)
In VirtualGL 2.1, we decided to wrap vglclient in a script that also
makes the X11-forwarded SSH connection. That is a much more robust
approach, because it ensures that vglclient's dependencies are working
before making the SSH connection. It also attaches a vglclient instance
to the X server, which makes sense architecturally because the VGL
Transport supplements the X11 connection. vglclient has worked that way
for 20 years. Before I could (literally) sign off on a new approach to
launching vglclient, I would have to spend a significant amount of time
figuring out the pitfalls (i.e. whether the issues that prompted us to
stop doing that in the first place) are still present on modern Macs,
testing and user-proofing the solution, and documenting it. Personally,
I don't see the need for such a solution, because all it really does is
prevent the need to type 'vglconnect' instead of 'ssh -X' when
connecting to a VirtualGL server.
Also, no one is paying me to change vglclient. These days, very few
people use vglclient except on Linux clients. It is still a fully
supported solution and will remain a fully supported solution, but it
works the way it works. I assume that you are getting paid a salary to
support the machines in question. If you need easily deployable
downstream customizations, then your employer can spend $100/year to
purchase an Apple Developer Program membership for you. You can refer
to my official build scripts
(https://github.com/virtualgl/buildscripts), and the packaging scripts
under release/ in the VirtualGL source tree, for an example of how to
create, sign, and notarize macOS packages. Those are things that your
employer will pay you to do, whereas I cannot get paid to do those things.