jupyter-remote-desktop-proxy
jupyter-remote-desktop-proxy copied to clipboard
jupyterhub
Define VNC servers to support
This project ships with TigerVNC, but has support for use with TurboVNC as well, and really any vncserver binary:
If a vncserver executable is found in PATH it will be used, otherwise a bundled TightVNC server is run. You can use this to install vncserver with support for other features, for example the Dockerfile in this repository installs TurboVNC for improved OpenGL support.
Should we aim for something simpler to reduce complexity and ensure robustness on what we really can manage to test and maintain? I'm thinking that we could remove TigerVNC for example.
Related
- With some users using one but not the other VNC server, it becomes harder to ensure bugs aren't introduced: #54
- TigerVNC has a different kind of license: #27
- TigerVNC doesn't support aarch64: https://github.com/jupyterhub/jupyter-remote-desktop-proxy/issues/27#issuecomment-1418646823
- TigerVNC doesn't support aarch64: Repository license is incorrect #27 (comment)
The bundled TigerVNC is x86_64 only.
Debian/Ubuntu has packages for both x86_64 and AArch64
I actually think we should just stop bundling a VNC server completely, and just require it be installed separately. This also solves the licensing issue.
I'd like to reach consensus on a path forward among us who have involved in thinking about this so far @cmd-ntrf @benz0li @yuvipanda.
- Question 1: Do we stop bundling TigerVNC?
- Question 2: Do we provide install scripts for TigerVNC and/or TurboVNC?
- Question 3: Do we commit to testing TigerVNC and/or TurboVNC?
Related
- TurboVNC's about page for TigerVNC at https://turbovnc.org/About/TigerVNC
- @cmd-ntrf draft PR removing TigerVNC and adding an install script for TigerVNC
Answer template
> **Question 1: Do we stop bundling TigerVNC?**
> **Question 2: Do we provide install scripts for TigerVNC and/or TurboVNC?**
> **Question 3: Do we commit to testing TigerVNC and/or TurboVNC?**
Question 1: Do we stop bundling TigerVNC?
Yes, its x86_64 specific and it has a licence we are breaking.
Question 2: Do we provide install scripts for TigerVNC and/or TurboVNC?
No, I don't think we should. If we do, we should have it for all the VNC clients we support. My motivation for not suggesting we introduce this is because of the maintenance burden we take on in this project that currently doesn't have tests setup. If we have tests setup, I'm open to re-evaluating this answer.
Question 3: Do we commit to testing TigerVNC and/or TurboVNC?
To me, this is the same as "Do we commit to supporting TigerVNC and/or TurboVNC". I'm open to supporting / testing both and, or just picking TurboVNC - but I'm hesitant to only pick TigerVNC based on what I've understood so far.
We now have tests for turbovnc and tigervnc and its far more clear now, closing as resolved!